Re: [myhdl-list] Block return values (myhdl.BlockError)

[Henry G. <he...@ma...>]

On 10/05/16 13:09, Henry Gomersall wrote:
> On 10/05/16 12:30, Jan Decaluwe wrote:
>> > On 10/05/16 12:02, Henry Gomersall wrote:
>>>> >> > On 10/05/16 10:45, Henry Gomersall wrote:
>>>>>> >>> >> On 10/05/16 10:32, Jan Decaluwe wrote:
>>>>>>>>>> >>>>> >>>> I have considered this issue for some time now
>>>>>>>>>> >>>>> >>>> and I have basically decided to leave the constraints
>>>>>>>>>> >>>>> >>>> as they are, that is, blocks should only return
>>>>>>>>>> >>>>> >>>> block and instantiator objects.
>>>>>> >>> >> I think your reasoning is sound.
>>>>>> >>> >>
>>>>>> >>> >> Do you object to alternative strategies for constructing Block
>>>>>> >>> >> operators? This could leave @block as the default usual case, with more
>>>>>> >>> >> esoteric cases handled by direct access to the construction of the Block
>>>>>> >>> >> object. This could allow the best of both worlds - simple default and
>>>>>> >>> >> arbitrary control if desired.
>>>> >> >
>>>> >> > Actually, a neat solution could be to allow optional decorator arguments
>>>> >> > taking the class constructor and allow subclassing of _Block.
>>>> >> >
>> > Independent of this feature, decorator arguments may be
>> > useful, but as you know a decorator without arguments
>> > behaves completely differently from a decorator with
>> > arguments.
>> > 
>> > Until now, the only way I saw to handle both cases
>> > with a single decorator was with some ad-hoc check
>> > that I didn't find very elegant.
> Yeah this is an issue. There's a somewhat neat way using keyword args
> exclusively, but it does require keyword args (which is not overly
> restrictive since this would be an "advanced" feature).
> 
> In this case it might work reasonably neatly in the simpler case though
> since we can check it's either a callable or a _Block, and reject
> anything else.

To be clear, what is seen by a naive user need not changed.

Both @block and @block(MyCustomBlock) can be made to work.

Speaking of that, another solution is to have something like an
@custom_block() decorator which _must_ take an argument.

Henry