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

rssh at gradsoft.com.ua rssh at gradsoft.com.ua
Sun Mar 22 08:51:24 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

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/

More information about the coin-dev mailing list