Re: [jamboost] class declaration syntax (was: Refactoring progress report)

From: Rene Rivera (grafik666_at_[hidden])
Date: 2003-05-10 15:37:20

[2003-05-10] David Abrahams wrote:

>David Abrahams <gclbb-jamboost_at_[hidden]> writes:
>
>> Hmm, a hybrid approach might be:
>>
>> rule [ class x : y z ] ( init-params )
>> {
>> ... init code ...
>> rule method1 ( whatever ) { ... }
>> }
>>
>> This one could work in similar ways, installing a rule-definition
>> hook; Although the previous approach has lots of appeal, I think
>> this one might be the most expedient.

[snip]

>But I don't think that's a particularly compelling case for anonymous
>functions; they'd be more useful in constructs like:
>
> # filter out elements of $(y) which aren't instances of my-class
> x = [ sequence.filter $(y) : bind ( elt ) is-instance $(elt) my-class ]
;

Not sure that's much of a win over a locally declared rule. It might even be
a loss as it's somewhat harder to read that the "is-instance $(elt)
my-class" is the body of function.

>In all, for class definition I prefer either of the following two
>syntaxes:
>
> # Overwrites __init__ in the local module; do we care?
> class myclass : base1 base2 
> __init__ ( param1 param2 ) 
> {
> base.__init__( param1 )
> rule foo_method ( bar ) { }
> } ;
>
> # No lambdas if we go this route; more syntax involved
> rule [ class myclass : base1 base2 ] ( param1 param2 )
> {
> base.__init__( param1 )
> rule foo_method ( bar ) { }
> }
>
>I think the 2nd one is easier to implement, and overall I view this as
>a low-priority issue.
>
>Thoughts?

I think I can more easily justify to my brain the second syntax. For me it
mentally parses as:

rule [ class myclass : base1 base2 ] ( ... )
^ ^-----------------------------^
| |
| +-Evaluate this to get the rule (which happens to be the class rule)
|
+-Normal rule declaration.

-- grafik - Don't Assume Anything
-- rrivera_at_[hidden] - grafik_at_[hidden]
-- 102708583_at_icq