Is @property implementable?

[Jonathan M Davis]

On Friday 04 March 2011 00:31:37 Kevin Bealer wrote:
> == Quote from Jonathan M Davis (jmdavisProg at gmx.com)'s article
> 
> > 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
> 
> I personally think strcpy got it wrong anyway -- everyone says 'input and
> output', not 'output and input', so it's weird to think of the output
> mentioned first. It's as if you wrote:
> 
> // everyone who uses this will get the argument order wrong at least once
> int everythingNice(int spice, int sugar);
> 
> But that's a side note...

IIRC, the assembly code used by gcc does it one way, and the assembly code used 
by Microsoft's compiler does it the other way. So, I've dealt with both, and 
which makes more sense to me depends on how I'm thinking on a particular day. I 
think that I'd be inclined to do target <- source rather than source -> target 
if I were choosing, but I've dealt with enough functions that did it both ways 
that it's not the kind of thing that I tend to assume. It just varies too much.

> Personally, I think the UFCS for anything but arrays is an engraved
> invitation to function hijacking.  Imagine defining this in your code:

If UFCS ever gets implemented, it will have to be in a way which avoids function 
hijacking, or there's no way that it will ever be implemented. D just plain 
doesn't support function hijacking. It's smarter/more restrictive than that. So, 
if UFCS can't be done without avoiding function hijacking, I don't expect it to 
ever be implemented.

That being said, I think that UFCS would potentially be very useful for 
implementing functions which act like they're part of a struct or class when 
they're not. For instance, I have one co-worker who is constantly irrated by how 
few functions C++'s std::string has and wants there to be more, but does not 
want to use utility functions, and pretty much no one else we work with wants to 
have a separate string class (as is done far too often in C++). Our current 
solution is a new string class that simply wraps std::string and allows us to 
add all of the functions that we need, but it would be much better were it 
possible to add free functions which could be used like member functions. _That_ 
is the sort of scenario that I, personally, think that UFCS would be valuable 
for. I see little to no value in stuff like 7.max(5). Using member function call 
syntax for arrays is fantastic, but I really don't think that it adds much for 
other types of primitives.

So, if UFCS can't be cleanly implemented for structs and classes, I don't really 
such much point to it, personally. But regardless, if UFCS is ever to be 
implemented, it needs to be done in a manner which completely avoids function 
hijacking or it will be unacceptable - especially to Walter.

Who knows whether we'll ever see UFCS or not, but its kinks will have to be 
worked out before it stands any chance of seeing the light of day.

- Jonathan M Davis