On Tue, Nov 3, 2009 at 10:47 AM, Ben <benoit.allard@gmx.de> wrote:
Hi Christopher,

On Tue, Nov 3, 2009 at 17:24, Christopher Felton <chris.felton@gmail.com> wrote:
>> The first solution I found is to make a always_comb process, but
>> still, we have to use a .next, so we don't have strictly the 'alias'
>> behavior. This solution is sort of driven by my "think hardware" mind,
>> or should I say, education.
>> The second solution I found, and there, MyHDL shows its supremacy, is
>> to use Python as a tool, and not define my ControlWord as intbv, but
>> to define my own class, say ctrlword that inherit from intbv, redefine
>> "__getattr__", such that "ctrlword.subpart3" return the right slice
>> from my intbv. THis also has the advantage that I keep complete
>> compatibility (think conversion) with the intbv type. Clever isnt't it
>> ? The only problem I got is that the intbv __copy__ function was
>> forcing the return value as being an intbv, thus, removing all the
>> information from my ctrlword.
> It might be better to override the methods/functions in your ctlrword class
> than removing them from the intbv object?  I did something similar with the
> fixed-point
> object, http://www.myhdl.org/doku.php/users:cfelton:projects:fxintbv, which
> is convertible, as well.

Actually, for completeness, this second solution still need a .next as
a slice still is an intbv and isn't a Signal, giving it as parameter
to a module kills it Signal nature. I still need to look at what can
be done at the Signal level for that.

Ok, I am slowing catching on to what you are trying to achieve.  In this case you might also have to cinherit the Signal class and override the update method in the Signal class.  Currently the Signal class has "next" handlers for the different types.  If the type passes isn't support an exception will occur.  Since it is a derived class of intbv it will use the default intbv "next handler"

Maybe this could be extended so that "type handlers" can be registered without creating a new derived Signal class.  I have done this before with numpy arrays but created a new class that inherits Signal and overloaded the update (_setUpdateType).  Others might have better suggestions or comments as well.

> Think this is/has been a sticky issue in the Python community in general.
>  Seems like there are strong opinions one way or the other.  In general an
> inheriting class needs to override all the base class methods to return the
> new type.

I would understand if the original function needs to do something,
actually , looking to the history of the code (thanks mercurial), this
function has been created returning a copy of "self._val", where it
would have made sense to define it, and later corrected to return a
copy of "self", where it doesn't make sense any more to define it as
the vanilla __copy__ from Python does the same, but taking care of

A "good" copy should looks like:
def __copy__(self):
   return self.__class__(self)

There, we wouldn't have had troubles.

> I believe you are asserting that the general copy returns the type of the
> object being copied and there is no need to override the copy methods?

That's right ! Even if it sound redundant, a copy of an object returns
a /copy/ of the same object : same value, same type.

That is a good point!  As you originally suggested the copy functions are no longer required.