Arbitrary abbreviations in phobos considered ridiculous

[Ary Manzana]

On 03/10/2012 02:06 AM, Andrei Alexandrescu wrote:
> On 3/9/12 5:05 PM, Adam D. Ruppe wrote:
>> On Friday, 9 March 2012 at 23:50:50 UTC, bearophile wrote:
>>> At first I didn't like it a lot because it's cheap syntax sugar that
>>> adds no new power and gives programmers more freedom to write
>>> different-looking versions of the the same code (and this is often bad).
>>
>> What I like about is the encapsulation benefits. You
>> don't have to know if the function is a method or an
>> external function, it just works.
>>
>> External, non-friend (so separate module in D) functions
>> are often preferable to methods because they don't have
>> access to the class' private members, so they cannot rely
>> on those implementation details.
>>
>> Extending objects with new functions in this way also
>> means you don't break binary compatibility with the
>> existing code, since it isn't modified at all!
>>
>>
>> Of course, you could always do this with the old
>> syntax too, but then the syntax preference means
>> you are biased toward one implementation or the
>> other - it doesn't mesh as well and you may be
>> tempted to make things methods for the syntax,
>> despite the cost in compatibility.
>>
>> UFCS rox.
>
> Insert obligatory link: http://drdobbs.com/184401197
>
> Very insightful article.
>
>
> Andrei

How can:

class Wombat {
   void nap() {
     this->sleep();
   }
}

increase encapsulation? It's using public API, so client code can't 
break if you keep the sleep method there.

Now, I do agree that it's nice to not have additional methods defined 
because it speeds up parsing and doesn't bloat the interface. I just 
don't agree with implementing it as UFCS.

Take a look a this:

void nap(Wombat wombat) { }
void somethingElse(Wombat wombat, int x) { }
void anotherThing(Wombat wombat, int x) { }

Compared to this:

class Wombat {
   void nap() {}
   void somethingElse(int x);
   void anotherThing(int x);
}

Shorter, grouped, cleaner (in my opinion). No repetition of Wombat all 
over the place.

In fact, it should be much easier to implement. When extending a class, 
associate those methods to the class, then do a normal lookup. With UFCS 
you'd have to look for a global function whose first parameter is the 
Wombat. So you have two searches: first find members, then public 
functions (I wonder why UFCS is not completely implemented so far).

Explaining an extension method is also easy: "If you extend a class's 
methods, those can only access public member functions". Now you'd have 
to say "Any global function that has this class as a first parameter can 
be invoked as a member function, removing this first parameter".

Well... I'm just looking for consistency.

This is exactly what happens in Ruby:

irb(main):001:0> Time.parse "2012-01-02"
NoMethodError: undefined method `parse' for Time:Class
	from (irb):1
	from :0
irb(main):002:0> require 'time'
=> true
irb(main):003:0> Time.parse "2012-01-02"
=> Mon Jan 02 00:00:00 -0300 2012

Well, in Ruby you can access private members in those extensions... I 
don't want that in D. So I guess one complaint for what I'm saying is 
"Oh, people will think that you can access private members in those 
extensions because they have the same syntax blah blah blah".