Re: [myhdl-list] Proposal: SignalType symbol

[Jan D. <ja...@ja...>]

Christopher Felton wrote:
>      > Your factory function Signal() must return the correct class object
>      > based upon the parameters passed to it.
>      >
>      > So Signal is just a function now that returns a class object so
>     there is
>      > no such thing as an instance of it.
> 
>     Right. For completeness, there is still the guarantee that any returned
>     object will be of type SignalType (so that the corresponding isinstance
>     check will always be true), but the specific subtype depends on the
>     parameters.
> 
> 
> Ok, I am  going to back up and make sure I understand this.
> 
> We have a base class, *Signal(...)* and derived classes DelayedSignal, 
> ShadowSignal, etc.  As you mentioned some earlier design decision guided 
> this path.  From a users point of view the desired effect is that they 
> only care about a *Signal* that may have some different attributes but 
> the user doesn't need to know that it is a different object (just 
> refreshing and sync'n out loud).
> 
> Now we have a factory function (introduced with the ShadowSignal) and a 
> proposed SignalType.  The SignalType exposes the actual base class 
> *_Signal_* because we can't have an instance of the factory function 
> (well you can but that is not the use here).  So the SignalType property 
> exposes the base class so we identify variable's types.

Correct. In effect, we decouple the interface to create Signal objects
from their base class SignalType. Everywhere where you tested where
an instance is a Signal, it should merely be a matter of using SignalType
instead.

Should I already push this change to the public repo's for experimenting?




-- 
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
    Python as a HDL: http://www.myhdl.org
    VHDL development, the modern way: http://www.sigasi.com
    Analog design automation: http://www.mephisto-da.com
    World-class digital design: http://www.easics.com