On 03/10/2012 10:03 PM, Ary Manzana wrote:
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).
I forgot to say: if you implement it by associating it to the type, you
can also use the current method lookup algorithm because it will search
in super classes. With UFCS you'd have to search for public functions
whose first parameter are B, then public functions whose first parameter
are A, etc, assuming A extends B.
So not only it's easier to write and read, but also easier to implement.
