July 24, 2009
Lutger wrote:
> Eldar Insafutdinov wrote:
> 
>> Ary Borenszweig Wrote:
> ...
>>> For instance properties seem to be a fundamental thing in Delphi and C#.
>>> When you are debugging and you watch some varaible, the debugger
>>> automatically allows you to expand a node and see the varaible's
>>> properties. You can't do that with D because any function that has zero
>>> parameters could be a property, even though some functions aren't
>>> properties.
>> While working on QtD I have also come up with the conclusion that D needs
>> proper properties. Qt itself greatly relies on properties and it makes a
>> lot of cool things possible. Of course C++ doesn't support them, it is
>> done via Qt metatype system. When D goes popular, IDEs will severely lack
>> this functionality from the language.
> 
> There have been a lot of discussions on this topic in the past but I can't recall any conclusions. Perhaps some brave soul would dare to write a DIP on  properties? 
> 
> 

Yes please.

Andrei
July 24, 2009
Rainer Deyke wrote:
> Walter Bright wrote:
>> Rainer Deyke wrote:
>>>   - Implementation inheritance of value types, even without actual
>>> polymorphism, is useful.  See, for example, the curiously recurring
>>> template pattern (and all of its uses).
>> You can do this with 'alias this'.
> 
> Composition instead of inheritance?  Doesn't work if I need virtual
> functions.

This is going in circles. You started from "implementation inheritance of value types, even without actual polymorphism".

Andrei
July 24, 2009
Jarrett Billingsley wrote:
> On Thu, Jul 23, 2009 at 5:56 PM, Michiel
> Helvensteijn<m.helvensteijn.remove@gmail.com> wrote:
>> Eldar Insafutdinov wrote:
>>
>>> from your post:
>>>
>>> property int length {
>>>     get() { return this.len; }
>>>     set(newLen) { this.len = newLen; }
>>>     void opIncrement() { this.len++; }
>>> }
>>>
>>> I don't think that's flexible to overload every operator to get the best
>>> performance. As Walter likes to say the best way should be the most
>>> obvious. Besides we forgot that D2 allows to return references, which
>>> eliminates the issue.
>> If your property really just hides a private member variable, it was
>> probably for encapsulation purposes or because you want redundant actions
>> to be taken for every access. If you return a reference, you give unlimited
>> and unrestricted access to that variable with only one call, and you might
>> as well not have used a property at all.
>>
>> If your property is derived -- that is, if it doesn't directly mirror a
>> variable --, there is no reference to return.
>>
>> Besides, in D, you can probably use mixins to copy the entire interface of a
>> type into the property without code duplication.
> 
> You're suggesting adding something like 25 operator overloads to every
> property.  Can you say "code bloat"?
> 
> Why not just use the following solution, which has been proposed
> God-knows-how-many-times and already has precedence in other languages
> (like C#)?
> 
> obj.prop op= value;
> 
> Simply becomes:
> 
> obj.prop.set(obj.prop.get op value);

I think this would be inefficient in many cases.

Andrei
July 24, 2009
On Fri, Jul 24, 2009 at 5:19 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:

>> obj.prop op= value;
>>
>> Simply becomes:
>>
>> obj.prop.set(obj.prop.get op value);
>
> I think this would be inefficient in many cases.

Um, what do you have to write now?  "obj.prop = obj.prop op value". All I'm suggesting is that the compiler automatically transform the expression for you.

Also, what someone else suggested - that it become "auto temp = obj.prop get; temp op= value; obj.prop.set(temp)" - is technically more correct, in terms of operator overloading (i.e. if the property returns a BigInt, or something).
July 24, 2009
Steven Schveighoffer wrote:
> On Fri, 24 Jul 2009 14:10:59 -0400, Walter Bright <newshound1@digitalmars.com> wrote:
>> That's my problem with properties as a distinct syntax - they don't have distinct uses or behaviors.
> 
> If you delineate what can be called how, then you elminate syntax ambiguities from occurring, and eliminate bizarro cases of syntax.  The difficulty is that the "human meaning" of a property is different than the human meaning of a function.  To the compiler, they're all functions, so you as the compiler writer aren't seeing that they are different.  I think we all agree that writefln = "hi"; makes absolutely no sense to a person.  But it makes complete sense to the compiler, because it has no idea what the word "writefln" means to a person.

But when I suggest a restriction on properties, I get complaints that someone might want to have them do what functions do. So I fail to see what rule distinguishes them from functions, even for people.


> It's the exact same reason + is not the concatenation operator.  Semantically, making + concatenate two strings together would be completely unambiguous from adding two integers together because strings do not define addition, and integers do not define concatenation.  From your own documentation, someone seeing "10" + 3 might think that he would get 13 or "103".  Even if the compiler defines what "should" happen, and the rules are unambiguous, it looks incorrect to the user.

Using + for concatenation is syntactically ambiguous with vector addition.
July 24, 2009
On Fri, Jul 24, 2009 at 2:19 PM, Andrei Alexandrescu<SeeWebsiteForEmail@erdani.org> wrote:
> Jarrett Billingsley wrote:
>>
>> On Thu, Jul 23, 2009 at 5:56 PM, Michiel Helvensteijn<m.helvensteijn.remove@gmail.com> wrote:
>>>
>>> Eldar Insafutdinov wrote:
>>>
>>>> from your post:
>>>>
>>>> property int length {
>>>>    get() { return this.len; }
>>>>    set(newLen) { this.len = newLen; }
>>>>    void opIncrement() { this.len++; }
>>>> }
>>>>
>>>> I don't think that's flexible to overload every operator to get the best performance. As Walter likes to say the best way should be the most obvious. Besides we forgot that D2 allows to return references, which eliminates the issue.
>>>
>>> If your property really just hides a private member variable, it was
>>> probably for encapsulation purposes or because you want redundant actions
>>> to be taken for every access. If you return a reference, you give
>>> unlimited
>>> and unrestricted access to that variable with only one call, and you
>>> might
>>> as well not have used a property at all.
>>>
>>> If your property is derived -- that is, if it doesn't directly mirror a variable --, there is no reference to return.
>>>
>>> Besides, in D, you can probably use mixins to copy the entire interface
>>> of a
>>> type into the property without code duplication.
>>
>> You're suggesting adding something like 25 operator overloads to every property.  Can you say "code bloat"?
>>
>> Why not just use the following solution, which has been proposed God-knows-how-many-times and already has precedence in other languages (like C#)?
>>
>> obj.prop op= value;
>>
>> Simply becomes:
>>
>> obj.prop.set(obj.prop.get op value);
>
> I think this would be inefficient in many cases.

That is true but I also think:
* probably that is the best that can be achieved automatically.
* if better can be achieved automatically then the compiler can just
do that under the hood.  No user code needs to change.
* set(get op value) probably won't be inefficient in some cases.
* having a op= b work automatically in an inefficient way is better
than forcing the users of the code to make the same ineffecient
transformation in their code manually (which is the status quo of
property syntax in D).

So I think how to make a op= b whizzy fast can be decided later.  And for now set(get op value) is good enough.

--bb
July 24, 2009
Ary Borenszweig wrote:
> Maybe what scares Walter is a whole new syntax for properties.

It doesn't scare me. It's trivial to add more syntax.

It's just that D is complex enough - there needs to be some very good reasons for adding more syntax that has apparently zero semantic information that would be different from the usual function syntax.
July 24, 2009
Michiel Helvensteijn wrote:
> That's just a few reasons right there. D's properties lack elegance and they
> lack potential.

Let's start with:

1. What is a property?

2. How is that different from, say, a pure function?
July 24, 2009
Steven Schveighoffer wrote:
> It's a good strategy for someone who's word is almost law when it comes to D.  You have to be careful what you say, flip-flopping around only leads to knee-jerk feature additions, more bikeshed discussions, and more people clammoring for feature additions (hey, you added this, why not that!).  I have great respect for the balance he has to deal with between adding interesting features and keeping a sane spec.

I spent literally all day in this thread yesterday. Each reply I make spawns several replies from others. It's exponential. At some point, I have to just stop <g>.
July 24, 2009
On Fri, Jul 24, 2009 at 2:44 PM, Walter Bright<newshound1@digitalmars.com> wrote:
> Michiel Helvensteijn wrote:
>>
>> That's just a few reasons right there. D's properties lack elegance and
>> they
>> lack potential.
>
> Let's start with:
>
> 1. What is a property?

"""
Properties are members that provide a flexible mechanism to read,
write, or compute the values of private fields. Properties can be used
as though they are public data members, but they are actually special
methods called accessors. This enables data to be accessed easily
while still providing the safety and flexibility of methods.
"""
-- thanks MSDN

> 2. How is that different from, say, a pure function?

Properties behave semantically like fields, but are implemented like
functions enabling them to do arbitrary calculation on the side when
the field is read from or written to.
Pure functions are totally different.  First, half of the property
syntax is about mutating a state.  That's obviously not pure.   And on
the get() side its returning the value of a mutable state, so again,
not pure.

--bb