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.
On 7/16/06, Paul Hammant <[EMAIL PROTECTED]> wrote:
>
> Seems like it could be do-able. If you don't strip the parameter
> names when you compile the Java code, they're available in the
> class files. You'd have to separately parse the class files to
> discover them, though since they're not exposed in the reflection
> API. It could be a little expensive to parse whole class files for
> small scripts that make use of named parameters.
>
Well for the most part, I'm talking about a first class change the
Java 6 or 7 where Class.class gets and extra getMethod(..) and
Method.class gets a getParameterNames().
However, and wondering of there is a case for a QDox leveraging
codehaus project that would gather method params, shove them in
a .txt file for inclusion in the jar, plus some fairly public-domain
code to access it for tools like JRuby (and a dozen web frameworks)
that would want to leverage it. It's about a days worth of code to
get to a usable 1.0.
- Paul
-------------------------------------------------------------------------
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
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ www.jruby.org
Application Architect @ www.ventera.com
------------------------------------------------------------------------- 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
