Re: Keyword Arguments

On Saturday, 9 June, 2012 at 4:48 PM, Kurtis Rainbolt-Greene wrote:
>   
> > Changed the arguments? Yes of course, reordered them? Not once, ever.
> > 
> 
> 
> Still doesn't make it a red herring.
> 
> 
> 
> 

Then we should agree to disagree on this point and move on.
> > How does keyword arguments help solve that problem? 
> 
> It doesn't solve that problem, but then I don't think I said it did. Here's the problems it solves:
> 
>   1. I have to order my arguments correctly
If you aren't doing this already, I don't think you have what it takes to be a programmer. Following instruction is part of problem solving, which is at the core of software development. 
>   2. I have no context for the values I'm passing
> 
> 
> 
> 
> 

You seem to think that I advocate many argument messages, which I don't. I've been very public on this list and others quite to the contrary. So much so that my language Acute, has a syntactic extension to Io (Jan-Paul was actually the one who wrote the parser support for it) that explicitly forbids multiple arguments. In these cases, it's a non-issue. If you can't make complex methods that require more than 2 arguments, you're probably designing your programs wrong. I'm not saying you can reduce everything to a one arg send, but I think if you're doing more than that, you probably are being lazy and not building a proper data structure to pass in. 
>   3. I have to look at the method definition to understand what value goes in what position
> 
> 
> 
> 
> 

Not necessarily, you could also look at the docs. Either way, you have to look at one or the other to know what the keywords are. I don't see how it differs. It's the same cognitive load, in different places. Again, red herring. 
> I can't tell you how it solves problems that I haven't said it solves.
I didn't claim you said it solved those problems, but given some of your other assertions, I figured it was worth asking. 
> 
> > You'll never have to do it again either. 
> 
> This is an entirely separate argument, but this doesn't help at all. I've pointed this out a few times: Implementing syntax sugar like this only makes things worse. By adding this on my own to my own Io implementation I now run into two problems: 
> 
>   1. My Io suddenly behaves differently from other people's Io. For instance, code I use this in will not run on other Io interpretors without first having them change and recompile their Io interpretor.
Then include your extension along side your program, problem solved. They'll get your version for your objects, and everyone's happy. 
>   2. Other implementations of Map literals are now barriers to entry for projects. I will either have to conform to their implementation, for their project only, or write an additional implementation of my own.
> 
> 
> 
> 
> 

No you don't, you expect a Map object, and you use the Map APIs internally. The lexer translates the literal into a valid series of message sends (specifically, a curlyBrackets message send, which returns a Map). Other implementations of Map literals would also return a Map object conceivably (otherwise they're doing it wrong), so again, it's a non-issue.
> Saying "Io doesn't have Map literals" is not a another way of saying "Please, give me another random way to implement Map literals on my own project/library/interpretor."
We've already had this argument, to which you stormed away all pissed. Let's not do it again. 

Regards,

Jeremy Tregunna