On Mon, 04 Sep 2006 15:44:52 -0700, Walter Bright wrote:

> Ivan Senji wrote:
>> Is there an example where replacing
>> 
>> f(a.prop);
>> 
>> with
>> 
>> auto x=a.prop; f(x); a.prop=x;
>> 
>> would be a bad thing to do, and could result in unexpected code, or hard
>> to catch bugs.
>> Sure some aspects of this behavior should be well documented to avoid
>> confusion (like the fact that the value is updated on function exit) but
>> it is the same with most other feature.
>> 
>> To make myself clear: D can do without this feature but without it a simple:
>> 
>> write f(a.prop) -> compile&run happily
>> 
>> is replaced with
>> 
>> write f(a.prop) -> compile -> goto line with error -> figure out the
>> error and how to fix it (might be hard the first time) ->
>> select "f(a.prop)" -> Ctrl-X -> write auto x=a.prop; f(x); a.prop=x; ->
>> compile&run (but less happily now)
> 
> I'd ask "why is f(x) returning a value in x?" That would normally be an
> essential part of the behavior of the function, so:
> 	f(3)
> should return an error, shouldn't it? If modifying its argument is an
> essential behavior of the function, and the argument is not modifiable,
> probably the programmer made a mistake and the compiler should not paper
> it over. And the same for every other argument that isn't an lvalue (and
> so cannot be set).
> 
> If you find yourself writing:
> 
>     auto x=a.prop; f(x); a.prop=x;
> 
> I would seriously question what is going on with f(). It's a big flag that something is wrong either with f() or with the usage of f(). I would not want the compiler papering it over.

What a load of BS. The user of 'prop' does not need to know how it's been implemented.

class A
{
   int prop;
}

class B
{
    private int q;
    void prop(int x) { q = x; }
    int prop() { return q; }
}

void f(inout int x)
{
    if (x < 0)
       x = -x;
}

A a = new A;
B b = new B;

f(a.prop);  // okay
f(b.prop);  // fubar




-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

Oskar Linde wrote:
> Derek Parnell wrote:
> 
>> On Mon, 04 Sep 2006 10:42:19 -0700, Walter Bright wrote:
>>
>>> Ivan Senji wrote:
>>>
>>>> Maybe not the right time to mention it but: one of the most annoying error messages dmd produces is "is not an lvalue". An annoying message isn't doesn't make a good first impression, and it makes an even worse second or third impression.
>>>>
>>>> Example:
>>>>
>>>>   class A
>>>>   {
>>>>     int xx = 11;
>>>>     int opIndex(int pos){return xx;}
>>>>     int opIndexAssign(int what, int pos){return xx = what;}
>>>>
>>>>     int prop(){return xx;}
>>>>     int prop(int newxx){return xx = newxx;}
>>>>   }
>>>>
>>>>   auto a = new A;
>>>>
>>>>   void f(inout int x)
>>>>   {
>>>>     x ++;
>>>>   }
>>>>
>>>>   f(a[5]);    //((a).opIndex)(5) is not an lvalue
>>>>   f(a.prop);  //((a).prop)() is not an lvalue
>>>>
>>>> Maybe a[5] isn't strictly an lvalue because it's adress can't be taken but, it would make much sense for the compiler to translate those cases to (and shouldn't be that hard to do):
>>>>
>>>> auto x = a[5];
>>>>   f(x);
>>>> a[5] = x;
>>>>
>>>> auto y = a.prop;
>>>>   f(y);
>>>> a.prop = y;
>>>>
>>>> I don't want to sound lika a D-hater because of my recent (complaining) posts but just trying to show that although D is a fantastic language it is still a little too rough around the edges.
>>>
>>> The compiler can translate those cases, but I feel that would be the wrong thing to do. If a function has inout for a parameter, it means that the function is expected to essentially return a value through the parameter. If the user calls a function with a parameter that cannot accept such a return value, it is most likely a mistake. If the compiler rewrites the code so it "works", then it's probably going to make finding the bug difficult.
>>>
>>> It's an error in C++ for the same reason (can't initialize a reference with a non-const).
>>
>>
>> You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
>> In fact, it could have been one until the class author changed it to a
>> property.  I feel that Properties need to behave as if they were data
>> members rather than methods when used as such. Thus ...
>>
>>   f(a.prop);
>> and
>>   f(a.prop());
>>
>> would look *and* behave differently but without surprising the coder.
>>
>> And this also means that
>>   a.prop++
>>
>> needs to work too. It is a great surprise to new comers that obvious things
>> like this are not working as expected.
>>
> 
> And what about:
> 
> a.prop.y = 7;
> 
> Where prop is/returns a struct { int x,y; } ?
> 

Easy enough, return a pointer to the struct.

But still.

-- Chris Nicholson-Sauls

Walter Bright wrote:
> 
> I'd ask "why is f(x) returning a value in x?" That would normally be an essential part of the behavior of the function, so:
>     f(3)
> should return an error, shouldn't it? 

Sure.

> If modifying its argument is an essential behavior of the function, and the argument is not modifiable, probably the programmer made a mistake and the compiler should not paper it over. 

Sure, but properties can be modifiable.

> And the same for every other argument that isn't an lvalue (and so cannot be set).
> 
> If you find yourself writing:
> 
>    auto x=a.prop; f(x); a.prop=x;
> 
> I would seriously question what is going on with f(). It's a big flag that something is wrong either with f() or with the usage of f(). I would not want the compiler papering it over.

I don't really understand why this should be a flag that something is wrong with f. There are probably good reasons why f isn't a member function, it is a generic algorithm.

Walter Bright wrote:

> An interesting question is: why are they using Java, and why strictly?

The answer is not as interesting - it was chosen when the company got started for reasons of easier portability between platforms and ease of learning (it started with some physics-related stuff, so at the time it was decided it's better to hire physicists and teach them to code rather than vice-versa).

Currently, porting the existing codebase is not really an option (the customers are satisfied enough with the Java version), while for new projects the management consistently decides it's better to go with a language/platform everybody here knows already, to minimize risk and maximize productivity (that Java is strictly used is more of an observation than a policy).

BTW, I still think you should add those array features, even though you decided to snip most of my post :P


xs0

On Tue, 05 Sep 2006 02:16:46 +0300, Derek Parnell <derek@psyc.ward> wrote:

> On Mon, 04 Sep 2006 15:15:15 -0700, Walter Bright wrote:
>
>> Derek Parnell wrote:
>>>> It's an error in C++ for the same reason (can't initialize a reference
>>>> with a non-const).
>>>
>>> You are right Walter. However, a[5] looks looks like an lvalue doesn't it?
>>> In fact, it could have been one until the class author changed it to a
>>> property.  I feel that Properties need to behave as if they were data
>>> members rather than methods when used as such. Thus ...
>>>
>>>   f(a.prop);
>>> and
>>>   f(a.prop());
>>>
>>> would look *and* behave differently but without surprising the coder.
>>>
>>> And this also means that
>>>
>>>   a.prop++
>>>
>>> needs to work too. It is a great surprise to new comers that obvious things
>>> like this are not working as expected.
>>
>> Whether it's consistent or not depends on how you think about it - what
>> your mental model is of it. I'd rather have the odd cases produce error
>> messages rather than have the compiler paper over what is likely a
>> programmer oversight.
>
> What 'odd case'?
>
> What 'programmer oversight'?
>
> The coder writes
>
>   a.prop++;
>
> because the 'prop' is a data item in the object that she wants to
> increment. It is irrelevant to the coder whether or not the class author
> decided to implement this data item as a property or data member. From the
> perspective of the user of the class, 'prop' represents some data in the
> object. The implementation details are not a concern for the user of the
> class.
>

I agree fully. I thought that the whole point was to hide the implementation from the user.

I sent a message "Suggestion: properties should be treated as 'virtual members variables'" to digitalmars.D concerning this issue (I think it deserves its own thread).

(I know that I have sent these suggestions quite many, hopefully nobody thinks that I'm raving that these features must be in D or it'll suck, or something... ;) I hope that they will -- at least -- cause discussion that could lead to new ideas and improvements for this great language.)

xs0 wrote:
> Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus
> 
> int[][][] foo;
> foo.length = 3;
> for (int a=0; a<3; a++) {
>     foo[a].length = 4;
>     for (int b=0; b<4; b++)
>         foo[a][b].length = 5;
> }
> 
> 
> xs0

That's a really bad comparison/argument, I believe you can template that code such that something like this can be used:

  auto foo = newAr!(int[3][4][5])();


-- 
Bruno Medeiros - MSc in CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D

Derek Parnell wrote:
> What 'odd case'?
> 
> What 'programmer oversight'?
> 
> The coder writes 
> 
>   a.prop++;
> 
> because the 'prop' is a data item in the object that she wants to
> increment. It is irrelevant to the coder whether or not the class author
> decided to implement this data item as a property or data member. From the
> perspective of the user of the class, 'prop' represents some data in the
> object. The implementation details are not a concern for the user of the
> class. 
> 

Oh, I see what you mean now. I had misunderstood. Sorry.

Walter Bright wrote:
> Derek Parnell wrote:
>> What 'odd case'?
>>
>> What 'programmer oversight'?
>>
>> The coder writes
>>   a.prop++;
>>
>> because the 'prop' is a data item in the object that she wants to
>> increment. It is irrelevant to the coder whether or not the class author
>> decided to implement this data item as a property or data member. From the
>> perspective of the user of the class, 'prop' represents some data in the
>> object. The implementation details are not a concern for the user of the
>> class.
> 
> Oh, I see what you mean now. I had misunderstood. Sorry.

What's the problem here? Is it hard to implement in the compiler or is unexpected behavior the problem? I think nowhere is unexpected behavior in "a.prop++". Just translate it to "a.prop = a.prop + 1".

If "a.prop" is a time consuming one, it should be great to be able to override the "++" and "--" meaning of the property, so that a 1 can be added or subtracted internally more efficiently. However, I can't imagine what the syntax could look like...

Ary

On Tue, 05 Sep 2006 12:40:47 -0700, Walter Bright wrote:

> Oh, I see what you mean now. I had misunderstood. Sorry.

That's ok. I have a huge problem with electronic expression. If we could talk face to face I wouldn't be nearly so obscure ;-)

-- 
Derek Parnell
Melbourne, Australia
"Down with mediocrity!"

xs0 wrote:
> BTW, I still think you should add those array features,

I probably will.

> even though you decided to snip most of my post :P

Please don't regard that as indicative of much of anything. I reply to posts generally mindful of how things will wind up in the archives pages which aggregate threads into one giant page. It looks better when previous article quoting is kept to the barest minimum, because the full text of the replied to article is right there anyway.