[erlang-questions] erlang improvement - objective c (or smalltalk) syntax

Sean Cribbs seancribbs@REDACTED
Thu Jun 4 18:32:32 CEST 2009


Joe,

First off, let me say that I love this idea. It immediately reminded me 
of Jim Weirich's talk about connascence and how to reduce coupling while 
increasing cohesion in your software (see 
http://mwrc2009.confreaks.com/14-mar-2009-18-10-the-building-blocks-of-modularity-jim-weirich.html). 


Jim says that Connascence of Name is of lesser degree than Connascence 
of Position; that is, in our example, the order of an argument list to a 
function creates a higher coupling than using named arguments.  A common 
pattern in Perl and Ruby that refactors CoP to CoN is to pass a hash/map 
of the arguments rather than place them in order, which accomplishes the 
same goal although it introduces a data structure that should be 
unneeded if the language supported named arguments.
> I *know* what the arguments are (a string, a start index and a length)
> but I have to
> consult the documentation to find the order.
>
> Solution: write the call like this.
>
>        string:substring( string:S start:I length:J)
>
> This could be expanded into a canonical form:
>
>        string:substring_start_string_length(S, I, J)
>
> where the tags are sorted.
>
>   
My first thought when I saw this was that the abstract form already 
contains the variable names, couldn't the compiler annotate the function 
appropriately using the existing names and negotiate them at runtime?  
If so, then it would just be a matter of renaming arguments in functions 
where they are named inappropriately, making the expansion unnecessary.  
Either way, it should be important to name or tag parameters 
consistently across the whole set of OTP libraries.

> This change has many advantages:
>
>             + forces use of meaningful tag names in arguments
>             + don't have to remember argument order
>             + variable names in the body of a function become shorter
>
>   
Unless there's some aspect of efficiency or performance that it 
provides, I don't see the value in the third point.  I feel it's much 
more important for the code to be intention-revealing.  That said, if 
parameters are tagged instead of used by name, the point is moot except 
to those maintaining the library.

Cheers,

Sean Cribbs

P.S. Can someone fix the Reply-To header on the list?  I unknowingly 
sent this to Joe only the first time!



More information about the erlang-questions mailing list