On Tuesday, 9 June 2015 at 08:58:19 UTC, Shachar Shemesh wrote:
but:
@property void func( ref A a, int b ) ...
should work. Same goes for dropping the () to zero arguments
function calls. Once that needs to be a conscious decision by
the programmer, my problems with UFCS are greatly reduced
(though, to be fair, not completely alleviated).
Yes, that mirrors my thoughts exactly. To me "a.propagate(b,c)"
reads completely different from "propagate(a,b,c)", just like
"a.start" and "a.start()" reads different (asking vs doing). I
want a language to enforce that.
When reading code I don't want to wonder if
"libraryobject.print()" is a function that is part of an external
library or if it is application code. I want that to be clear
when skimming over the source. No IDE can help with that without
adding clutter.
I therefore find extension-methods are more suitable for objects
that are self-contained (like integer and string) and less
suitable for objects that are facades for complicated machinery.
The module/encapsulation subsystem for language BETA allows local
extensions by injecting them into library-defined slots in the
AST. That way the library author get some control over what you
can extend.
I also don't add methods much to objects in dynamic languages
where this is integral to the programming model, only as a quick
hack. Subclassing is usually the better option. Which is
reflected in Python by the adding of a new class type with
restrictions on expanding the type.
