Method invocation -- why it's not working?

[H. S. Teoh]

On Fri, Mar 09, 2012 at 03:10:00AM -0800, Jonathan M Davis wrote:
> On Thursday, March 08, 2012 08:03:09 H. S. Teoh wrote:
[...]
> > 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.
> 
> Yeah. That says _nothing_ about UFCS working with types other than
> arrays. It clearly states that the discussion of how to add them to
> user-defined types is discussed in the next chapter (which is on
> classes and includes defining member functions which are methods or
> properties without any UFCS stuff with free functions). It then
> specifically asks the question about what to do about arrays and then
> goes into an explanation about how you can define free functions which
> can use member invocation syntax and property syntax.  _Nowhere_ does
> it discuss adding free functions which work for other built-in types
> (such as int or float), and _nowhere_ does it discuss using free
> functions to add member functions to classes or structs via UFCS.

Um... did you even read the second quoted paragraph? Andrei did not say
'a' is specifically an array. He said it's a type for which fun is not a
member function. It's entirely reasonable to understand Andrei's wording
as meaning that the rewrite from a.fun(b,c,d) --> fun(a, b, c, d) is
intended to be generically across any type of 'a'. It's an exposition of
the form "we can make X work for user-defined types, but X doesn't work
for arrays because we can't add members to arrays. But don't worry, D
also has feature Y, so in the case of arrays, using feature Y solves the
problem."

As to whether this was his actual intention, it's not for me to say. But
do not be surprised if many people interpret that paragraph to mean that
UFCS works across all types.


> I think that it's crystal clear that it's _not_ talking about UFCS but
> rather simply using member invocation syntax with arrays.

The wording is ambiguous. He said "but fun is not a member of a's type".
Why would he say "member of a's type" if he was only referring to
arrays? If I were to write that paragraph, and I only intended the
rewrite to happen with arrays, I'd word it quite differently. It would
be much clearer to say, for example, "if a.fun(b,c,d) is seen but fun
isn't an array method, then D rewrites that as fun(a,b,c,d) and tries
that as well." The fact that he chose to say "member of a's type"
suggests that it was a generic feature.


> So, while we may very well end up with UFCS in the language on some
> level (if not completely implemented in all its glory), TDPL does
> _not_ discuss UFCS. It _only_ discusses member invocation syntax on
> arrays. So, if UFCS were to never happen, it wouldn't contradict TDPL.
[...]

I'm not going to pick a fight with you, but I'm just saying that, as it
stands, the wording suggests that the rewrite from a.fun(b,c,d) to
fun(a,b,c,d) happens across the board. Andrei did not make it clear that
only arrays were intended. So even if he didn't *intend* for this
rewrite to happen for all types, a reader who didn't know any better
would assume that it did work across all types, because of the
genericity of the wording.


T

-- 
Being able to learn is a great learning; being able to unlearn is a greater learning.