Re: [myhdl-list] [PATCH] Remove redundant copy operators

[Ben <ben...@gm...>]

Hi Christopher,

On Tue, Nov 3, 2009 at 17:24, Christopher Felton <chr...@gm...> 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.

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

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.

Regards,
Benoit