PRE-PROPOSAL: Named method parameters with defaults.

[Reinier Zwitserloot]

Making them final doesn't help at all.

The extra keyword is neccessary because I don't see any other way of  
making it work. Annotations aren't the right vehicle for this, as has  
been said many times on the coin-dev list.

There are other parsers out there, yes, and I'm an opponent of context- 
sensitive keywords, but that decision has -already- been made:  
'module' is going to be a context-sensitive keyword in java7, and no  
amount of chatter on coin-dev is going to change this. I'm rolling  
with it :)

  --Reinier Zwitserloot
Like it? Tip it!
http://tipit.to



On Mar 22, 2009, at 08:27, rssh at gradsoft.com.ua wrote:

>>
>> The 'named' is a new context sensitive keyword (if 'module' can be
>> one, then this isn't too much of a stretch), and, only for named
>> methods, you can supply expressions that serve as defaults. Each
>> expression is evaluated exactly once, during your class  
>> initialization
>> (so, the ArrayList above is SHARED amongst all method invocations! -
>> I'd force it to be immutable but java does not have such a facility).
>>
>
> It is possible to restrict default parameters be final. It's not  
> exactly
> 'immutable' but better than nothing.
>
>>
>>
>> Three questions:
>>
>> A) Is this a good idea? Do you like it? Would you use it? (I think  
>> its
>> stellar, but then, I'm proposing it).
>>
>
> for me - all ok except extra keyword. I think that it is possible do  
> not
> add new keyword (by example - using annotation, which can be not only
> package-level, but class-level (for all methods) and package-level(for
> all classes in packages and subpackages); IMHO better just view all
> method as
> named, cost of incompatibility is less, than cost of adding new word  
> in
> near each method definition)
>
> //Also Note, that javac is not only implementation of java parser,  
> exists
> many parsers in tools, build with javacc and antrlr, wich have no  
> support
> for 'context-depended' keywords in grammar. Adding each 'context- 
> depended'
> framework to such grammars is non-trivial hack.
>
>
>
>> B) Did I miss something (is it more complicated than I make it out to
>> be), or is something unclear? Specifically, did I miss something that
>> does not make it backwards, migration, and source compatible?
>>
>> C) Might this be within scope for project coin? I'll definitely write
>> it up if it stands a chance.
>>
>>
>>  --Reinier Zwitserloot
>>
>>
>>
>> On Mar 21, 2009, at 18:56, Marek Kozieе┌ wrote:
>>
>>> Builders are really great tool, but they need to be written  
>>> manually.
>>>
>>> In other way there will be problem, if final object need contains  
>>> data
>>> and builder only key for that data.
>>>
>>>
>>>
>>> --
>>> Pozdrowionka. / Regards.
>>> Lasu aka Marek Kozieе┌
>>>
>>> http://lasu2string.blogspot.com/
>>>
>>
>>
>>
>
>