www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Property modifying rvalue

reply Vathix <vathix dprogramming.com> writes:
class Foo
{
    static void prop(inout int x)
    {
       x = 3;
    }
}

int main()
{
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);

    return 0;
}


Output:

num = 0
num = 3


Looks a little backwards ;)  just thought I'd mention it.
May 15 2005
next sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
I guess it is a feature rather than a bug :)

E.g. it allows to implement transfer of ownership.

struct Foo
{
   char[] _buffer;
   void buffer(inout Foo x)
   {
       _buffer = x._buffer;
       x._buffer = null;
    }
}

Huh?


"Vathix" <vathix dprogramming.com> wrote in message 
news:op.sqt37ts4kcck4r esi...
 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }

 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);

    return 0;
 }


 Output:

 num = 0
 num = 3


 Looks a little backwards ;)  just thought I'd mention it. 
May 15 2005
prev sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Vathix wrote:
 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }
 
 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);
 
    return 0;
 }
That looks extremely counterintuitive to me! 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). What do you think? James McComb
May 15 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 09:28:17 +1000, James McComb wrote:

 Vathix wrote:
 class Foo
 {
    static void prop(inout int x)
    {
       x = 3;
    }
 }
 
 int main()
 {
    int num = 0;
    printf("num = %d\n", num);
    Foo.prop = num; // Innocent assignment.
    printf("num = %d\n", num);
 
    return 0;
 }
That looks extremely counterintuitive to me! 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). What do you think?
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. 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. -- Derek Melbourne, Australia 16/05/2005 9:34:02 AM
May 15 2005
next sibling parent reply James McComb <ned jamesmccomb.id.au> writes:
Derek Parnell wrote:

 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.
Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :) James McComb
May 15 2005
next sibling parent reply "Unknown W. Brackets" <unknown simplemachines.org> writes:
Are you paying these people?

Who's to say a class couldn't need this, as Andrew Fedoniouk described?

-[Unknown]


 Derek Parnell wrote:
 
 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.
Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :) James McComb
May 15 2005
parent reply James McComb <ned jamesmccomb.id.au> writes:
Unknown W. Brackets wrote:
 Are you paying these people?
No. They're my co-workers.
 Who's to say a class couldn't need this, as Andrew Fedoniouk described?
A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax? James McComb
May 15 2005
next sibling parent "Unknown W. Brackets" <unknown simplemachines.org> writes:
Ah, there, you said the exact reason - "to me, anyway".  I ain't you.

-[Unknown]


 Who's to say a class couldn't need this, as Andrew Fedoniouk described?
A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax? James McComb
May 15 2005
prev sibling parent "Andrew Fedoniouk" <news terrainformatica.com> writes:
 A class could need that *behaviour*. Why would it need to use property 
 *syntax*, when they could use the less confusing (to me, anyway) function 
 syntax?
There are a lot of languages passing parameters by values only. So inout parameter in function will be also weird for apologists of these languages. whatewer. One might say : lets remove references in C++ as memebers of my team can do: class Foo { void Bar(const T& t) const { const_cast<Foo*>(this) -> .... const_cast<T&>(t). ..... } } All above does not mean that D is perfect at this stage... It is good, but not perfect yet. Andrew. "James McComb" <ned jamesmccomb.id.au> wrote in message news:d698bk$121s$1 digitaldaemon.com...
 Unknown W. Brackets wrote:
 Are you paying these people?
No. They're my co-workers.
 Who's to say a class couldn't need this, as Andrew Fedoniouk described?
A class could need that *behaviour*. Why would it need to use property *syntax*, when they could use the less confusing (to me, anyway) function syntax? James McComb
May 15 2005
prev sibling parent Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 12:19:35 +1000, James McComb wrote:

 Derek Parnell wrote:
 
 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.
Hey, I *like* languages that are hobbled based on what is good coding practices! It's the only way to guarantee that the other members of my team use good pracises (code reviews have no effect on them)! :)
Sack them then! A good team plays by the team rules. When team members from any of my teams have trouble with reviews or following standards, they are told to shape up or ship out. If they persist in bring down the team, they are moved off the team. A flexible language means that different teams can have different rules and standards. For example, my rules and my standards are not regarded as sufficient by some other people, and unless they are in one of my teams, I'm okay with that. They are free to convince me to change my views, as I believe it is reasonable to assume that my views could possibly be wrong or need updating. -- Derek Melbourne, Australia 16/05/2005 12:25:08 PM
May 15 2005
prev sibling next sibling parent reply "Jarrett Billingsley" <kb3ctd2 yahoo.com> writes:
"Derek Parnell" <derek psych.ward> wrote in message 
news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...
 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.
Oh come now, D is based around taking all the "gotchas" out of C/C++. An expression such as blah.x=num; Where num is affected is a pretty big gotcha if you ask me! Now, if we were _required_ to state parameters as out or inout when calling the functions ;) then this problem wouldn't exist. It would be syntactically illegal to write: blah.x=inout num; You would have to write blah.x(inout num); Making the intent that num is modified clearer.
May 16 2005
parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:

 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...
 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.
Oh come now, D is based around taking all the "gotchas" out of C/C++. An expression such as blah.x=num; Where num is affected is a pretty big gotcha if you ask me!
Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a fairly stupid idea too. However, I cannot make myself start advocating against it *in every circumstance* because there may very well be a reasonable justification for it in some special situation that I have yet to hear about. To ban it based on the premise that it is a "gotcha" is ammunition to ban GOTO (and other constructs) from the language too.
 Now, if we were _required_ to state parameters as out or inout when calling 
 the functions ;) then this problem wouldn't exist.  It would be 
 syntactically illegal to write:
 
 blah.x=inout num;
 
 You would have to write
 
 blah.x(inout num);
 
 Making the intent that num is modified clearer.
But if "blah.x=inout num;" is not illegal then this would also express the coder's intent. In any case, you can 'ban' it from your code right now by doing ... blah.x = (num+0); -- Derek Melbourne, Australia 17/05/2005 11:33:18 AM
May 16 2005
parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:
 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:
 
 
"Derek Parnell" <derek psych.ward> wrote in message 
news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...

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.
Oh come now, D is based around taking all the "gotchas" out of C/C++. An expression such as blah.x=num; Where num is affected is a pretty big gotcha if you ask me!
Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a fairly stupid idea too. However, I cannot make myself start advocating against it *in every circumstance* because there may very well be a reasonable justification for it in some special situation that I have yet to hear about. To ban it based on the premise that it is a "gotcha" is ammunition to ban GOTO (and other constructs) from the language too.
Now, if we were _required_ to state parameters as out or inout when calling 
the functions ;) then this problem wouldn't exist.  It would be 
syntactically illegal to write:

blah.x=inout num;

You would have to write

blah.x(inout num);

Making the intent that num is modified clearer.
But if "blah.x=inout num;" is not illegal then this would also express the coder's intent. In any case, you can 'ban' it from your code right now by doing ... blah.x = (num+0);
I don't know why you like hackish code, buty um, this has nothing common with GOTO. the GOTO is a low level construct, it's evil, but sometimes you may need it when you do low level stuff. The keyword here is *low level*, D wants to be a systems programming language, like C and C++, and not just an application language, like properties are (somewhat) high level constructs, there is no rational for them to behave unexpectedly. Just in what way would it help D to have something like object.propery = value; change "value" instead of "property"?!
May 16 2005
next sibling parent reply Hasan Aljudy <hasan.aljudy gmail.com> writes:
Hasan Aljudy wrote:
 Derek Parnell wrote:
 
 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...

 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.
Oh come now, D is based around taking all the "gotchas" out of C/C++. An expression such as blah.x=num; Where num is affected is a pretty big gotcha if you ask me!
Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a fairly stupid idea too. However, I cannot make myself start advocating against it *in every circumstance* because there may very well be a reasonable justification for it in some special situation that I have yet to hear about. To ban it based on the premise that it is a "gotcha" is ammunition to ban GOTO (and other constructs) from the language too.
 Now, if we were _required_ to state parameters as out or inout when 
 calling the functions ;) then this problem wouldn't exist.  It would 
 be syntactically illegal to write:

 blah.x=inout num;

 You would have to write

 blah.x(inout num);

 Making the intent that num is modified clearer.
But if "blah.x=inout num;" is not illegal then this would also express the coder's intent. In any case, you can 'ban' it from your code right now by doing ... blah.x = (num+0);
I don't know why you like hackish code, buty um, this has nothing common with GOTO. the GOTO is a low level construct, it's evil, but sometimes you may need it when you do low level stuff. The keyword here is *low level*, D wants to be a systems programming language, like C and C++, and not just an application language, like properties are (somewhat) high level constructs, there is no rational for them to behave unexpectedly. Just in what way would it help D to have something like object.propery = value; change "value" instead of "property"?!
I forgot to mention that this is just a syntatic sugar, purly a syntactic sugar. There is *NO* situation where it becomes necessary to write hack.prop = value; instead of hack.prop(value); to change "value".
May 16 2005
parent Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:05:08 -0600, Hasan Aljudy wrote:

 Hasan Aljudy wrote:
 Derek Parnell wrote:
 
 On Mon, 16 May 2005 21:19:59 -0400, Jarrett Billingsley wrote:


 "Derek Parnell" <derek psych.ward> wrote in message 
 news:1vzzrty491tc3$.57da8e828nm0$.dlg 40tude.net...

 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.
Oh come now, D is based around taking all the "gotchas" out of C/C++. An expression such as blah.x=num; Where num is affected is a pretty big gotcha if you ask me!
Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a fairly stupid idea too. However, I cannot make myself start advocating against it *in every circumstance* because there may very well be a reasonable justification for it in some special situation that I have yet to hear about. To ban it based on the premise that it is a "gotcha" is ammunition to ban GOTO (and other constructs) from the language too.
 Now, if we were _required_ to state parameters as out or inout when 
 calling the functions ;) then this problem wouldn't exist.  It would 
 be syntactically illegal to write:

 blah.x=inout num;

 You would have to write

 blah.x(inout num);

 Making the intent that num is modified clearer.
But if "blah.x=inout num;" is not illegal then this would also express the coder's intent. In any case, you can 'ban' it from your code right now by doing ... blah.x = (num+0);
I don't know why you like hackish code, buty um, this has nothing common with GOTO. the GOTO is a low level construct, it's evil, but sometimes you may need it when you do low level stuff. The keyword here is *low level*, D wants to be a systems programming language, like C and C++, and not just an application language, like properties are (somewhat) high level constructs, there is no rational for them to behave unexpectedly. Just in what way would it help D to have something like object.propery = value; change "value" instead of "property"?!
I forgot to mention that this is just a syntatic sugar, purly a syntactic sugar. There is *NO* situation where it becomes necessary to write hack.prop = value; instead of hack.prop(value); to change "value".
That maybe true. And there is also no reason to code "value++" instead of "value = value + 1" -- Derek Melbourne, Australia 17/05/2005 1:40:27 PM
May 16 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
On Mon, 16 May 2005 21:01:53 -0600, Hasan Aljudy wrote:

 Derek Parnell wrote:
[snip]
 Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
 fairly stupid idea too. However, I cannot make myself start advocating
 against it *in every circumstance* because there may very well be a
 reasonable justification for it in some special situation that I have yet
 to hear about.
 
 To ban it based on the premise that it is a "gotcha" is ammunition to ban
 GOTO (and other constructs) from the language too.
 
[snip]
 I don't know why you like hackish code, buty um, this has nothing common 
 with GOTO.
Who said I liked "hackish" code? ;-)
 the GOTO is a low level construct, it's evil, but sometimes you may need 
 it when you do low level stuff.
GOTO is not evil because it is low-level; it is evil because it tends to increase the cost of maintaining code.
 The keyword here is *low level*, D wants to be a systems programming 
 language, like C and C++, and not just an application language, like 

 
 properties are (somewhat) high level constructs, there is no rational 
 for them to behave unexpectedly.
 
 Just in what way would it help D to have something like
 object.propery = value;
 change "value" instead of "property"?!
I have no idea at all in what way this might help D. But because of the fact that I don't know, does not automatically mean that there is no good reason for it, it just means that I don't know it. Somebody else might know or discover it. Anyhow, if it coded as "object.property = inout value;" the reader would be aware of potential side-effects. Consider ... object.property = ++value; This also modifies the right hand side identifier, but because of the "++" prefix the reader is made aware of that. -- Derek Melbourne, Australia 17/05/2005 1:31:35 PM
May 16 2005
parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
Derek Parnell wrote:
 On Mon, 16 May 2005 21:01:53 -0600, Hasan Aljudy wrote:
 
 
Derek Parnell wrote:
[snip]
Oh I agree its a fairly stupid thing to do, just as I believe GOTO is a
fairly stupid idea too. However, I cannot make myself start advocating
against it *in every circumstance* because there may very well be a
reasonable justification for it in some special situation that I have yet
to hear about.

To ban it based on the premise that it is a "gotcha" is ammunition to ban
GOTO (and other constructs) from the language too.
[snip]
I don't know why you like hackish code, buty um, this has nothing common 
with GOTO.
Who said I liked "hackish" code? ;-)
the GOTO is a low level construct, it's evil, but sometimes you may need 
it when you do low level stuff.
GOTO is not evil because it is low-level; it is evil because it tends to increase the cost of maintaining code.
The keyword here is *low level*, D wants to be a systems programming 
language, like C and C++, and not just an application language, like 


properties are (somewhat) high level constructs, there is no rational 
for them to behave unexpectedly.

Just in what way would it help D to have something like
object.propery = value;
change "value" instead of "property"?!
I have no idea at all in what way this might help D. But because of the fact that I don't know, does not automatically mean that there is no good reason for it, it just means that I don't know it. Somebody else might know or discover it.
Like I said, it's just a syntactic sugar, it doesn't do anything differently, so there is nothing to discover, except maybe for the ability to produce obfuscated code. All you're doing is removing the brckets and adding an "=" equals sign. What would be the circumistance where it becomes usefully more benefitial than obj.prop(val); It's a syntactic sugar, it adds no new abilities to the language.
 
 Anyhow, if it coded as "object.property = inout value;" the reader would be
 aware of potential side-effects.
I would rather have the compiler produce an error if a function is defiend like this: property(out value) [...] and called like this: property = value; The simple solution is that this property syntactic sugar is only legal when value is not "out" i.e. when the compiler knows that the method "property" does not change "value". the suggestion object.property = inout value; is just pointless, it's not a syntactic sugar, it's a syntactic complication. What's the point of it? If we're gonna do that, we might as well just get rid of this sugar as a whole.
 
 Consider ...
 
   object.property = ++value;
 
 This also modifies the right hand side identifier, but because of the "++"
 prefix the reader is made aware of that. 
 
This is different, ++value is an expression that returns a value, it's not a variable. Just like: obj.prop = val = x; (I don't know if that's legal in D) Where (val = x) is an expression that returns a value (returns x).
May 16 2005
prev sibling parent reply Brian White <bcwhite precidia.com> writes:
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".
 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 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. This restricts nothing since a slightly different syntax accomplishes the exact same thing and with much better clarity. Let's not have people shooting themselves in the foot when they don't even realize that what they're holding is a gun. Brian ( bcwhite precidia.com ) ------------------------------------------------------------------------------- In theory, theory and practice are the same. In practice, they're not.
May 18 2005
next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Brian White" <bcwhite precidia.com> wrote in message 
news:d6g56c$3mt$1 digitaldaemon.com...
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".
Keep in mind there are many ways to abuse inout with innocent looking syntax. For example operator overloading can be used: struct Foo { int opAdd(inout int y) { y = 10; return 20;} } int main() { Foo x; int y = 1; int z = x+y; // changes y assert( y == 10 ); return 0; } I think in this case if people want to abuse inout and syntacitc sugar they can.
May 18 2005
parent Vathix <vathix dprogramming.com> writes:
 Keep in mind there are many ways to abuse inout with innocent looking
 syntax. For example operator overloading can be used:

 struct Foo {
     int opAdd(inout int y) { y = 10; return 20;}
 }
 int main() {
     Foo x;
     int y = 1;
     int z = x+y; // changes y
     assert( y == 10 );
     return 0;
 }

 I think in this case if people want to abuse inout and syntacitc sugar  
 they
 can.
This might be a reason to require function callers to specify out/inout, and it would be impossible to specify that for properties and overloaded operators, as a nice little side affect. For example: class Foo { static void func(inout int x) { x = 4; } static void prop(inout int x) { x = 3; } } int main() { int num; Foo.func(num); // error: must specify inout. Foo.func(inout num); Foo.prop = num; // error: must specify inout. Foo.prop = inout num; // error: bad syntax. return 0; }
May 18 2005
prev sibling parent reply Derek Parnell <derek psych.ward> writes:
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
May 18 2005
next sibling parent Hasan Aljudy <hasan.aljudy gmail.com> writes:
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.
May 18 2005
prev sibling parent Brian White <bcwhite precidia.com> writes:
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)
May 19 2005