Method invocation -- why it's not working?
H. S. Teoh
hsteoh at quickfur.ath.cx
Fri Mar 9 09:44:28 PST 2012
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. :-)
There are four kinds of lies: lies, damn lies, and statistics.
More information about the Digitalmars-d-learn