PRE-PROPOSAL: Named method parameters with defaults.

[rssh at gradsoft.com.ua]

> 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

 Why not made all methods be with named parameters by default ?
For classes, which compiled with pre-7 compiler, just use defaults values
for names, for example _1, _2, .. etc.


> been said many times on the coin-dev list.
>

 Hmm, I missed something (?)   Sorry, can you point me to right mail in
archive or tell why annotations is impossible. ?
I remember annotation critics but with same reasons, as I criticize new
keywords.


> 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 :)
>

 One hack better than two hacks, .... which is better then 100 hacks.
But you are right - this is question of taste.

>   --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/
>>>>
>>>
>>>
>>>
>>
>>
>
>