@property - take it behind the woodshed and shoot it?

[kenji hara]

I can imagine a situation that we might not want to treat property
functions as DATAs simply.

If you have a struct which have some property functions as members, and
you'd want to serialize it:

struct S {
   int value_;
   @property int value() { return value_; }
}

At least, the serialization library should recognize the S.value is a
_property function_, not a int DATA.

In most case, property functions should be treated as a simple DATA field.
but in a few case, it shouldn't. I have thought AddressExpression &func is
one of the places.

Related bugzilla issue I posted:
http://d.puremagic.com/issues/show_bug.cgi?id=9062

Kenji Hara

2013/1/25 Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>

> On 1/24/13 4:56 PM, Adam Wilson wrote:
>
>> Simplicity is clearly good, but there's something to be said about
>>> those warts in chained calls. The UFCS-enabled idioms clearly bring a
>>> strong argument to the table, there's no ignoring it.
>>>
>>> Andrei
>>>
>>
>> Then @property needs to be fixed such that optional parens don't effect
>> it one way or the other. Removing the concept of properties and making
>> functions that look like properties through optional parens is a very
>> poor (and lazy) solution. As Mr. Ruppe pointed out, properties are DATA,
>> and functions do stuff. That statement alone is an excellent argument
>> for clearly delineating which is which... Properties are not functions.
>>
>
> I'm not all that convinced, and it's easy to get wedged into a black vs
> white position that neglects many subtleties. Properties are DATA, well
> except when you need to pass fields by reference etc. at which point the
> syntactic glue comes unglued.
>
> There's been a lot of strong positions years ago about functions vs.
> procedures, statements vs. expressions, or even (the glorious 60s!)
> in-language I/O primitives vs. I/O as library facilities. Successful
> languages managed to obviate such dichotomies.
>
>
> Andrei
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130125/1f4bd180/attachment-0001.html>