Is @property implementable?
Jonathan M Davis
jmdavisProg at gmx.com
Thu Mar 3 08:25:06 PST 2011
On Thursday 03 March 2011 01:31:38 Jacob Carlborg wrote:
> On 2011-03-03 08:16, Jonathan M Davis wrote:
> > On Wednesday 02 March 2011 23:12:43 %u wrote:
> >>> Well, it wouldn't be universal then. For a function to be treated
> >>
> >> as a property, it would require an annotation, but universal
> >> function call syntax isn't supposed to require an annotation any
> >> more than calling a function on an array as if it were a member
> >> function requires an annotation. It's supposed to work with any
> >> function.
> >>
> >> So are you saying a hypothetical function like
> >>
> >> char[] strcpy(char[] destination, const char[] source);
> >>
> >> should be callable like:
> >> myString.strcpy(myString2);
> >>
> >> ?
> >>
> >> Isn't that asking for disaster, since it does the exact opposite of
> >> what the user expects (since the source and destination are
> >> switched)?
> >>
> >> I think we need an annotation for this (even for arrays), since
> >> otherwise it's too easy to go wrong.
> >
> > How are the destination and source switched? The arguments are in the
> > exact same order, only now one of them is to the left of the function
> > name. It's been like this with arrays for a long time. It's not going
> > away, and it's not going to require an annotation. That would be a big
> > change to the language, and the ability to call arrays like this is
> > well-liked and often-used. And a number of people definitely want
> > uniform function call syntax to be implemented so that it works for all
> > types.
> >
> > I don't see what's easy to go wrong with this syntax. It's quite
> > straightforward. It's been around for quite a while. And it's well-liked.
> > It's not going to be changed. The only question is whether it's ever
> > going to be implemented for types in general.
> >
> > - Jonathan M Davis
>
> What I think he means is, if you see a function call like this:
>
> myString.strcpy(myString2);
>
> You would expect "myString" to be the source and "myString2" the
> destination.
But that's not how the function is written. The left parameter is the
destination. If myString.strcpy(myString2) is confusing, I would expect
strcpy(myString, myString2) to be just as confusing. I don't see how using the
member function call syntax like that makes it any more confusing. Not to
mention, functions with a source and destination like that end up in both orders
all the time, so I don't think that you can generally expect it in one order or
the other anyway.
- Jonathan M Davis
More information about the Digitalmars-d
mailing list