PRE-PROPOSAL: Named method parameters with defaults. (original) (raw)

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

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

More information about the coin-dev mailing list