PRE-PROPOSAL: Named method parameters with defaults.
reinier at zwitserloot.com
Sun Mar 22 07:07:03 PDT 2009
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 :)
Like it? Tip it!
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
>> (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
> 'immutable' but better than nothing.
>> Three questions:
>> A) Is this a good idea? Do you like it? Would you use it? (I think
>> stellar, but then, I'm proposing it).
> for me - all ok except extra keyword. I think that it is possible do
> 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
> near each method definition)
> //Also Note, that javac is not only implementation of java parser,
> many parsers in tools, build with javacc and antrlr, wich have no
> for 'context-depended' keywords in grammar. Adding each 'context-
> 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
>>> In other way there will be problem, if final object need contains
>>> and builder only key for that data.
>>> Pozdrowionka. / Regards.
>>> Lasu aka Marek Kozieе┌
More information about the coin-dev