possible "solution" for ufcs

[Lutger Blijdestijn]

Steven Schveighoffer wrote:

> On Mon, 06 Jun 2011 17:07:25 -0400, Lutger Blijdestijn
> <lutger.blijdestijn at gmail.com> wrote:
> 
>> Nice and clever! However, I don't think it's good as an alternative for
>> ufcs
>> in the language, unless that is going to be dropped because of too many
>> ambiguities.
> 
> I admit I'm not warm and fuzzy on arbitrarily extending interface.  For
> one, having functions in one place makes docs/members easy to look up.
> i.e. I can look at one file and know all the operations for a datatype,
> and I can look at a function call and know where to find it in the
> documentation.  I'm a firm believer that an object's author should be in
> charge of the interface to his object.  Hence my position on enforcing
> strict @property syntax.

I understand. What I find most attractive about ufcs is not really about 
extending interfaces, but making function composition saner to read. In some 
libraries such as jquery and linq it's very clean to compose operations, 
because they work well with chaining. Although it's not the same, something 
similar (and actually much better) could be achieved with ranges + ufcs. 
Ranges want to be composed, yet I find myself often introducing temporary 
variables to avoid a mess of nesting. Libraries with chaining are more 
pleasant, imho.

I'll readily believe that the problems are significant though. Another issue 
may be function hijacking: when I call bar.foo() where foo is my extension, 
and the author of bar adds a foo method to it's type, the behavior silently 
changes. Your proposal does give some control over that.

> However, ranges are really not in that league -- all operations on ranges
> are pretty much external.  Only the primitives live in the type.  This is
> something that is accepted and understood.  The same thing with slices.
> So it's natural to want to use ufcs there.

To me, this would be a big improvement on the usability of ranges. Not 
saying ranges aren't usable, but this would make for much shorter and 
readable code. 
 
> BTW, we've had several people who think capacity should be in std.array,
> but it is actually in core.object, this is due to the disjoint nature of
> slice members -- they live everywhere.  This will only get worse.
> 
>> ufcs should imho be a decision on the caller side or the side of the
>> function extending a datatype (like extension methods in C#), not the
>> implementor of a datatype. It should ideally be available out of the
>> box, to
>> be used with any type.
> 
> I am OK with ucfs being available everywhere, but the ambiguities are
> difficult to work around.  Especially for properties.
> 
> My preference is that UFCS be supported only for builtin language types
> (slices, fixed-size arrays, primitives) because there is no other option
> for extension, and we should work on allowing author-sponsored
> extendability in custom types.  Type wrapping in general needs a lot more
> support from the compiler and IFTI.
> 
> The author can even explicitly only allow extendability of certain
> function names, with the ability to use template constraints on
> opDispatch.  I just think it's an area we *already* need to work on, and
> given this solution, it naturally allows better ufcs as you can wrap
> functions better.
> 
> -Steve