Method invocation -- why it's not working?

[H. S. Teoh]

On Fri, Mar 09, 2012 at 08:50:36AM -0800, Jonathan M Davis wrote:
> On Friday, March 09, 2012 07:56:15 H. S. Teoh wrote:
> > 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.) ...
[...]
> > 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.
> 
> I see nothing ambiguous about it, because it _clearly_ says at the end
> of the previous paragraph that it's talking about arrays. Obviously,
> it's confusing some people, but I find it very weird that it is.
> Regardless, if you don't think that the text is clear enough, then
> Andrei would have to say what he intended. But I just don't see how
> you could really think that it's talking about anything other than
> arrays when it clearly says that it's talking specifically about T[],
> and all of the examples use arrays. But I guess that we can just leave
> it at that.
[...]

The way I understood it was that he was introducing a more general
concept as a solution that also applies to arrays.

But anyway. There's no point arguing about this. I need to get back to
working on the druntime AA implementation. :-)


T

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