On Sep 27, 2006, at 9:55, Barry Ferg wrote:
Johannes, if as you say "many people do this kind of thing in many
circumstances", why limit their ability to do so in this circumstance?
I'm simply acknowledging that many people do this.
Of course, a substantially larger number of people doesn't do this.
For example, there is a reason why most people prefer
interface Foo {
public String getName();
}
over
interface Foo {
public String [] getName();
}
just to be safe in case some instance of Foo might have two names
some day. (There are some who always do the second.)
This proposal doesn't _force_ anyone to us multiple parameters
with the same name. I'm in favour of keeping the specification
flexible by not imposing unnecessary restrictions on future
extensions to the protocol.
For that matter, isn't having implementation issues in certain
restrictive development environments drive the specification kind
of like the tail wagging the dog?
I'm not making that argument (although it shouldn't be ignored
either). The argument I'm making is that an equally important problem
occurs on a higher level, which is harder to solve than writing a few
additional pack or unpack routines.
On 26-Sep-06, at 4:44 PM, Johannes Ernst wrote:
On Sep 26, 2006, at 16:13, Josh Hoyt wrote:
I think the real topic of this discussion is whether or not multiple
parameters with the same name should be allowed by the
specification.
I'd support the motion of not doing that.
I realize many people do this kind of thing in many circumstances,
but in my experience, it always turns out to be more trouble than
it's worth.
Johannes Ernst
NetMesh Inc.
http://netmesh.info/jernst
_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs
