On 7/17/06, Paul Hammant <[EMAIL PROTECTED]> wrote:
I think it's because of the way Java developer expect things to work. Because we have static typing, because we can refactor, we do. Variable names change as their usage patterns change, and so should they be expected to. Up to now making a method public has come with a very specific contract: the method name/signature and behavior should be expected to behave mostly the same from here on out. Broadly changing that contract now opens a very large can of worms...suddenly the internal naming of parameters would be exposed and would have to be a new part of that contract.
The other half of this is that named parameters *may* increase readability, but I don't think that's the real purpose. 99% of the method calls I make are passed mostly variable names. How could fetchResults(query, criteria) be made more readable? Only when callers pass a lot of literals do named parameters have an impact on readability.
I think there's also a concern about style and naming across libraries and applications. If I use two different libraries, one which calls a set of criteria "criteria" and one which calls it "specification" do I end up mixing code that specifies named parameters for both? What about devs who like to use underscores? Dollar signs? If I want to use named parameters, I'm not only at the mercy of a library's developers, I'm at the mercy of their (lack of) standard naming conventions as well. Caveat emptor, certainly, but I can't think of another feature that exposes so much with so little control over the eventual side-effects.
From what I can gather (though it's still a bit unclear) Ruby 2.0 will also require you to explicitly declare named parameters (aka keyword arguments). matz made a number of proposals last year, but I've been unable to find whether there's been any final decision. Many disliked what he proposed, and some of the options may be needlessly complicated. The simplest follows; the others were just more complicated mixings of named and unnamed params.
def foo(a:, b:2)
..
end
foo(a:3, b:4) # a = 3, b = 4
foo(b:4, a:3) # a = 3, b = 4
foo(a:3) # ok, b defaults to 2
foo() # error, a has no default value
foo(1, 2) # error, no positional arguments
foo(b:4) # ditto
foo(c:5) # error, no parameter c
So even in a language as syntax-averse as Ruby, matz hopes to make named parameter support explicit rather than implicit. It could be argued that they're doing this partially because of limitations in the C implementation of Ruby, but I think it's more reasonable to *add* named params to an already-established language rather than to suddenly make *all* params work as named params.
I can agree to disagree :)
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.
I think it's because of the way Java developer expect things to work. Because we have static typing, because we can refactor, we do. Variable names change as their usage patterns change, and so should they be expected to. Up to now making a method public has come with a very specific contract: the method name/signature and behavior should be expected to behave mostly the same from here on out. Broadly changing that contract now opens a very large can of worms...suddenly the internal naming of parameters would be exposed and would have to be a new part of that contract.
The other half of this is that named parameters *may* increase readability, but I don't think that's the real purpose. 99% of the method calls I make are passed mostly variable names. How could fetchResults(query, criteria) be made more readable? Only when callers pass a lot of literals do named parameters have an impact on readability.
I think there's also a concern about style and naming across libraries and applications. If I use two different libraries, one which calls a set of criteria "criteria" and one which calls it "specification" do I end up mixing code that specifies named parameters for both? What about devs who like to use underscores? Dollar signs? If I want to use named parameters, I'm not only at the mercy of a library's developers, I'm at the mercy of their (lack of) standard naming conventions as well. Caveat emptor, certainly, but I can't think of another feature that exposes so much with so little control over the eventual side-effects.
From what I can gather (though it's still a bit unclear) Ruby 2.0 will also require you to explicitly declare named parameters (aka keyword arguments). matz made a number of proposals last year, but I've been unable to find whether there's been any final decision. Many disliked what he proposed, and some of the options may be needlessly complicated. The simplest follows; the others were just more complicated mixings of named and unnamed params.
def foo(a:, b:2)
..
end
foo(a:3, b:4) # a = 3, b = 4
foo(b:4, a:3) # a = 3, b = 4
foo(a:3) # ok, b defaults to 2
foo() # error, a has no default value
foo(1, 2) # error, no positional arguments
foo(b:4) # ditto
foo(c:5) # error, no parameter c
So even in a language as syntax-averse as Ruby, matz hopes to make named parameter support explicit rather than implicit. It could be argued that they're doing this partially because of limitations in the C implementation of Ruby, but I think it's more reasonable to *add* named params to an already-established language rather than to suddenly make *all* params work as named params.
I can agree to disagree :)
--
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
