From: Christophe Grandsire Date: 2005-10-21T17:12:55+09:00 Subject: Re: A comparison by example of keyword argument styles Selon Brian Mitchell : > > My s_ method is messy and could probably be cleaned up but it still > serves a point. Savor the style for a bit. It might add more verbosity > but I think it gives us some good side effects for the small price > (IMHO again). I think some really good points can be made for both > side but my _feeling_ is that Ruby doesn't need another halfway there > feature (IMHO). Keyword arguments are serious things and should be > treated as part of your interface (IMHO). I feel that the semantics of > m_ are more clear than the at first simpler look of s_ (IMHO -- why > not just automatically append these till the end of my message). It is > a hard choice. We still have one more option that I know of, change > nothing. Hashes seem to get the job done for most people already. I > know I missed something so please add to this. If I made any errors > please correct them. Just avoid and unproductive and personal attacks > please. > Thanks for the post Brian. I want to say that I agree with your conclusion that matz's proposal is right now the best one. As I said on RedHanded, it's indeed a question of interface. Keyword arguments are, when looking at them from an interface point of view, like Smalltalk or Objective-C's multiword methods: keyword arguments are part of the *name* of the method (that's even stronger than being part of its signature IMHO). Positional arguments are *not* part of the name of the function. Their position is part of its signature, but that's all. Mixing both styles, positional and keyword, is thus a bad idea IMHO. It's mixing things that exist on different levels. Keyword arguments, being just a part of the name of a method, must be explicitly marked as such by the developer, and shouldn't be allowed to be left out by the user, just like you can't leave out the name of a method. Implicitly making all arguments keyword arguments is like implicitly making all arguments names part of the name of the method: it is actually more restrictive than having to explicitly mark the keyword arguments (then you can at least choose which arguments are part of the name of the method and which not). Adding to that the possibility to call keyword arguments in a positional way and you get a recipe for disaster. If, as a developer, you want some arguments to be keyword arguments, make them explicitly so: *mean* it. Having half-baked semi-keyword-semi-positional arguments is like not being able to choose between two desserts on the menu, after an already heavy dinner: choose one or the other, but don't take both. Besides the higher check, there's quite a chance you'd end up sick. -- Christophe Grandsire. http://rainbow.conlang.free.fr It takes a straight mind to create a twisted conlang.