On Mon, 06 Jun 2011 17:07:25 -0400, Lutger Blijdestijn
<[email protected]> 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.
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.
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
