On Wed, 18 May 2005 15:31:24 -0400, Brian White wrote:

>>>What about this idea? The property syntax Foo.prop = num should only be allowed where prop takes an in argument. If the argument is out or inout, D should force you to use the function syntax Foo.prop(num).
> 
> I think that would be just fine.  Personally, I think banning all calls to functions via "=" would be fine, too, but it's not a big deal. However, in the case where an offending line looks perfectly innocent and has such a potentially disasterous side-effect, then it should definitely be banned.
> 
> As someone else said, part of D's philosophy is to remove "gotchas".

Right, like "Foo a; a.Bar();"  ;-)

> 
>> It's the designer's or coder's choice. If they choose to use inout *and* treat it as an inout parameter, that is their choice, and probably made for a very good reason.
> 
> It may not be a designer's choice.  The code could be a module written by someone else and imported.  An assignment should not modify an rvalue.  If you can provide some examples of those "very good reasons", I'd appreciate it.

I've already said that I can't do that because I don't know any. But just
because I don't know any doesn't automatically mean that there aren't any.

> 
>> I can't see why we should hobble the language based on 'what is good coding practices'. If that was the case, the GOTO might not live very long ;-) We should permit the language to enhance the coder's freedom of coding practices, even if one doesn't approve of some.
> 
> All languages are hobbled.

I know. Do you think I said otherwise?

I did say (to paraphrase) "restricting a languages syntax based only on what some people regard as poor coding standards is not to be encouraged".

>  This restricts nothing since a slightly
> different syntax accomplishes the exact same thing and with much better
> clarity.

Just to clarify, doesn't 'restrict' mean 'prevent full access or usage'. Therefore I would think that preventing access *to this syntax* is actually a restriction.

> Let's not have people shooting themselves in the foot when they don't even realize that what they're holding is a gun.

The same reasoning could be used to ban the use of assembler coding. I believe the risk-mitigation strategies for this are called 'documentation' and 'education'.

-- 
Derek Parnell
Melbourne, Australia
19/05/2005 6:51:04 AM

Derek Parnell wrote:
[snip]
> The same reasoning could be used to ban the use of assembler coding.
> I believe the risk-mitigation strategies for this are called
> 'documentation' and 'education'.
> 


Well, the reason I liked D and go into it was because it removes all the "gotchas" from C/C++ (well, not /all/ of them) but that's something that is needed in a new language like D. Or else, what's the use of it? We can just stick to C++.

http://www.digitalmars.com/d/overview.html

I also like D for not being toooo restrictive (like Java).

But restrictions are not necessarily a bad thing.

I don't think that disallowing the property behaviour on methods that take an inout/out parameter is a bad restriction, it's a good restriction.
The property syntax sugar (as I understand) is for redundant accessor methods on classes, it's meant to simplify things, not complicate them.

The problem here is that it's really hard to assume that
obj.prop = value;
would change the value .. this just bloats the language with "gotchas". What's the purpose then?

Like I said again and again, there can be no cases where this type of syntax becomes necessary, it's just a sugar, not a feature.

>>>>What about this idea? The property syntax Foo.prop = num should only be allowed where prop takes an in argument. If the argument is out or inout, D should force you to use the function syntax Foo.prop(num).
>>
>>I think that would be just fine.  Personally, I think banning all calls to functions via "=" would be fine, too, but it's not a big deal. However, in the case where an offending line looks perfectly innocent and has such a potentially disasterous side-effect, then it should definitely be banned.
>>
>>As someone else said, part of D's philosophy is to remove "gotchas".
> 
> Right, like "Foo a; a.Bar();"  ;-)

Unfortunately, D is not entirely successful in its attempt.  I also made a post yesterday about this ambiguity (which may be what the ";-)" is about or it may be because I was bitten by this... not sure) on D.learn.  Search the subjects for "opEquals ambiguity" and you should find it.

But not being entirely successful doesn't provide reason to be more unsuccessful.


>>>It's the designer's or coder's choice. If they choose to use inout *and*
>>>treat it as an inout parameter, that is their choice, and probably made for
>>>a very good reason.
>>
>>It may not be a designer's choice.  The code could be a module written by someone else and imported.  An assignment should not modify an rvalue.  If you can provide some examples of those "very good reasons", I'd appreciate it.
> 
> I've already said that I can't do that because I don't know any. But just
> because I don't know any doesn't automatically mean that there aren't any.

Well... I don't recall anybody providing good reasons.  So, with very good reasons why this can be problematic, complete absense of evidence to the contrary, and a perfectly legal alternate syntax that at least hints of possible side-effects...  Why allow it to be used?


> I did say (to paraphrase) "restricting a languages syntax based only on
> what some people regard as poor coding standards is not to be encouraged".
>
>> This restricts nothing since a slightly 
>>different syntax accomplishes the exact same thing and with much better clarity.  
> 
> Just to clarify, doesn't 'restrict' mean 'prevent full access or usage'.
> Therefore I would think that preventing access *to this syntax* is actually
> a restriction.

Okay...  Let me define "restrict" as "limiting the coder in what can be accomplished".  Then, there is no restriction because the exact same thing can be accomplished with a different and better (because it at least hints that it may be modified since all paramaters can be) syntax.


>>Let's not have people shooting themselves in the foot when they don't even realize that what they're holding is a gun.
> 
> The same reasoning could be used to ban the use of assembler coding.
> I believe the risk-mitigation strategies for this are called
> 'documentation' and 'education'.

I'd say that when you code in assembler, you _know_ you're holding a gun.  I'd also say that you're doing it because there is no other way to accomplish the desired results.

                                          Brian
                                 ( bcwhite@precidia.com )

-------------------------------------------------------------------------------
 "I can't complain but sometimes I still do."  -- Joe Walsh (Life's Been Good)