Is @property implementable?

[spir]

On 03/04/2011 09:31 AM, 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.

Yes, I really agree, but (unfortunately?) we write
	target = source;

> 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...
>
> Personally, I think the UFCS for anything but arrays is an engraved invitation to
> function hijacking.  Imagine defining this in your code:
>
> int find(T, U)(T a, U b)
> {
>      ...
> }
>
> class Foo {
>      int find(double x, char[] y);
> };
>
> Foo x;
> x.find(a, "hello"); // would this call the template or the method?
>
> Whoops -- now every class, structure, and array in your program has a method
> called find() that hijacks any arguments that don't exactly match an existing
> function.  If you call x.find(), you can't know if you are getting the method in
> the class or a free function that got sucked in because of this syntax.  Of course
> if you get the signature exactly right it probably prefers the method over the
> free function.  Arrays are special because the only methods they have are *built
> in* methods.  Thus, a basic understanding of the language makes it possible to
> avoid the ambiguity.  But implementing UFCS for other types is a problem.
>
> If I do "a.getIndex(5)" and the compiler says there is no method getIndex on class
> A, this is a gift --- it is almost always the case that this is an error.  I doubt
> I ever want getIndex(A, int) but wrote A.getIndex(5) or where I wanted f(A, int)
> but wrote a.f(5).
>
> If you want another method in your class *add it to your class*.  The reason it
> makes sense to have it for arrays is so that you can define common methods across
> all your types like "serialize" method or "toString" or "deepCopy" and know what
> these methods do.  Then you can use them in templates.  Arrays can't be subclassed
> to add the methods so you need a way to produce the same syntax as a method call.
>
> Since arrays can't be derived from, UFCS fills in a real gap and doesn't mask
> existing or future methods unless the interface for arrays changes which is rare,
> we hope.  Allowing it for other types doesn't fill a gap, it creates an
> overlap/ambiguity.  It doesn't let you do anything you can't already do.  It's
> like a built-in alias this that you can't turn off and that matches across all the
> free functions of the world if I'm understanding the matching correctly.
>
> In most cases you can also use functions (for deepCopy etc) to work with both
> classes and arrays, but this doesn't work with virtual functions, so the method
> syntax is nicer for that.  So UFCS is justified to make arrays 'look like classes'
> to template code.  But it's not justified in my opinion to make classes look like
> classes with one more method.

I was a supporter of UFCS, but my opinion starts to change.
The main point for me was to allow client code enhance structs/classes 
according to specific needs. Eg you import a stream class and add it a 
'serialize' pseudo-method. But now I start to think
1. libraries should be designed in such that this need is rare enough
2. one can and should subtype, thus making clear it's a new version

Unfortunately, this is not possible for structs (the 'alias this' hack is not 
subtyping (*), it's plain delegation instead). The absence of struct subtyping 
is a big drawback. Why is it so? (**)

Denis

(*) There is no common supertype, so one cannot have a func or collection 
accept both the original type and one or more customized types. And indeed 
there is no method dispatch.
(**) Some OO languages have struct-like types (stack-allocated, 
value-semantics) *with* subtyping. See eg Oberon for a wonderful example.
-- 
_________________
vita es estrany
spir.wikidot.com