I guess we're going to disagree on whether parameter names should eternally remain contractual or not, or subject to revision despite everyone's hope that that many be avoided. I see libraries and apps that code against param names to to be on the periphery for Java, never the main stream. And is see annotations/attributes spread like a cancer thru Java when transparency should be thing people aim at. If names params come in Ruby 2.0, I wonder how it will be used - Ruby is already pretty terse from the method declaration and use point of view - I can't see much changing, and people would vent blood in the Ruby community if methods had to be marked to make the usable_by_param_name. Why does the Java community have to put up with an annotation based scheme, when no lang changes are actually needed.
Despite the fact that Rails is obsoleting other web technologies, there is still innovation in the Java world, that reduces the keystrokes necessary to code it -> http://waffle.sourceforge.net/ Never mind, unless you you turn on the topic, I'll drop it now. We're otherwise deep in the hypotheticals (how future webapps written for JRuby may more transparently access underlying Java object models, and similar). - Paul On Jul 16, 2006, at 10:32 PM, Charles O Nutter wrote: > Named parameters may be an issue in the future. Ruby 2.0 is > supposed to support named parameters, which could potentially > complicate compilation for us. It could also just be an arg- > processing issue, reordering incoming parameters to match up with > the order of names. > > I read your blog entries (Paul) about named parameters in Java 6 > (now Java 7, so it would seem) and have a few comments I'll just > toss out here. This will all eventually affect JRuby, so I think > it's relevant. > > I think named parameters are a very useful tool, but I think they > also break a certain amount of encapsulation we've come to depend > on in Java. What I call my parameters is none of a caller's > business...unless I choose to make it their business. The standard > for Java has always been to hide first, expose when specified. > Classes, methods, and fields are not public by default. Local > variables are inaccessible to everyone outside that scope. > Parameter names should be the same. I believe that with Java as it > exists today, there should be no parameter name exposure by > default. If you want to expose parameter names, I think you must > use per-param annotations (yick) or per-method annotations > (better). The onus is then on the API developer to expose parameter > names, rather than on the API client to be cautious when using > them. The contract has always been the same...if you make something > public, people will expect it not to change. Parameter names > should, like everything else, be hidden by default, and only when > you opt to expose them are you explicitly signing up for the > contract of maintaining them. > > All that said, I'd like to see named params in a future version of > Java. It comes up again and again within my circle of friends here > in Minnesota: without a doubt the coolest things being done with > Java are in the dynamic space. Be it dependency injected > containers; smart objects for persistence, STM, or web development; > or dynamic language implementations...everything that's really > helping people get shit done is dynamic. I think it's a logical > progression to move the JVM toward support for dynamic programming > in all its forms, finally putting to rest the hard-nosed static > world. I hope we on the JRuby project can do our little part to > break down that wall. > ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Jruby-devel mailing list Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
