Re: [myhdl-list] Proposal: SignalType symbol

[Christopher F. <chr...@gm...>]

>
> > 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.

Ok, if I am on the same page, this all works from my perspective.  I will
double check in the cases were I accessed the private properties as a work
around.  It will be a couple days before I can check.

I like the approach and having access to identify a variables type!  If I
remember correctly, I was using in in my mixed DSP sim environment (models
and RTL) and had assertions to verify the ports in the DSP blocks were
Signals, the proposed solution should be applicable in my use cases.

.chris