Method invocation -- why it's not working?

[H. S. Teoh]

On Wed, Mar 07, 2012 at 11:50:57PM -0800, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 08:37:38 Comrad wrote:
> > On Thursday, 8 March 2012 at 06:43:45 UTC, Jonathan M Davis wrote:
[...]
> > It's not correct. In TDPL it is clearly stated, that this is a
> > general feature of the language.
> 
> Then please give me a page number. Last time I looked it over, I saw
> _nothing_ which said that it worked on types in general, and _all_
> examples used arrays.

TDPL, p.156, 1st two paragraphs under 5.9.1 "Pseudo Members and the
@property Attribute":

	One syntactic problem is that function invocations so far have
	looked like fun(argument), whereas now we'd like to define calls
	that look like argument.fun() and argument.fun. The latter
	syntaxes are called method invocation syntax and property access
	syntax, respectively. We'll learn in the next chapter that
	they're rather easy to define for user-defined types, but T[] is
	a build-in type. What to do?

	D recognizes this as a purely syntactic issue and allows
	pseudo-member notation: if a.fun(b,c,d) is seen but fun is not a
	member of a's type, D rewrites that as fun(a, b, c, d) and tries
	that as well. (The opposite path is never taken, though: if you
	write fun(a, b, c, d) and it does not make sense, a.fun(b, c, d)
	is not tried.) ...

In the second paragraph, it seems that it should apply to all types,
since Andrei says "but fun is not a member of a's type". If 'a' were to
be restricted only to arrays, why did he say "a's type"? Why didn't he
say "but fun is not an array method" or something along those lines?
Granted, the context is speaking about arrays, but the wording "a's
type" seems to be intentionally generic.


[...]
> It would be nice, but I honestly don't understand the people who think
> that the lack of it is crippling. It's just one of those nice-to-have
> features.  Most languages don't have anything of the sort.
[...]

It *is* crippling if you're trying to write generic code, like Andrei
was doing with find() in the TDPL page I quoted above. You just invented
a new algorithm that abstracts away certain primitives that you'd like
to generalize across all types. So now you merrily go along and
implement primitive1, primitive2, etc., in all your struct's and
objects. But then you run into built-in types, and discover that UFCS
doesn't work for that type. I'd say that *is* rather crippling. You'd
have to special-case all relevant primitive types, which defeats the
purpose of generic code (imagine if find() and family had to be special
cased for arrays -- there'd be a lot of code bloat in std.algorithm).


T

-- 
There are four kinds of lies: lies, damn lies, and statistics.