www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Is DMD 0.166 RC 1.0?

reply Walter Bright <newshound digitalmars.com> writes:
Any compelling reason why not? I know that everyone (including me) wants 
more features, more improvements, etc., but nothing about calling it 1.0 
will prevent that from happening.
Sep 02 2006
next sibling parent reply BCS <BCS pathlink.com> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Are you talking about DMD or D? I think that all *D* needs is some editing of the spec (disambiguating, typo corrections, etc.) A feature freeze NOW wouldn't bug me a bit. DMD on the other hand has a ways to go. I've got a few pet peeves* and there is a bunch of known issues under dstress and the issue list. Lastly after D is declared 1.0 RCn, DMD should be confirmed to actually (for the most part) implement it correctly before it is declared 1.0. For that I'm thinking of a systematic sweep of the spec where test cases are generated for as many parts as can be managed. Each test case should be confirmed to work or be tagged as a correct program (a.k.a a known issue). Submitting these to dstress might be a good idea also. *> http://d.puremagic.com/issues/show_bug.cgi?id=52
Sep 02 2006
parent Juan Jose Comellas <jcomellas gmail.com> writes:
BCS wrote:

 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants
 more features, more improvements, etc., but nothing about calling it 1.0
 will prevent that from happening.
Are you talking about DMD or D? I think that all *D* needs is some editing of the spec (disambiguating, typo corrections, etc.) A feature freeze NOW wouldn't bug me a bit. DMD on the other hand has a ways to go. I've got a few pet peeves* and there is a bunch of known issues under dstress and the issue list. Lastly after D is declared 1.0 RCn, DMD should be confirmed to actually (for the most part) implement it correctly before it is declared 1.0. For that I'm thinking of a systematic sweep of the spec where test cases are generated for as many parts as can be managed. Each test case should be confirmed to work or be tagged as a correct program (a.k.a a known issue). Submitting these to dstress might be a good idea also. *> http://d.puremagic.com/issues/show_bug.cgi?id=52
I think this is an important distinction to make. The D spec may be ready and DMD might be ready on Windows too, but the Linux version is far from being usable for any kind of production environment. Once DMD on Linux generates correct debug information, allows the creation of shared libraries and has no code generation problems (see http://d.puremagic.com/issues/show_bug.cgi?id=315) we could probably talk about it. Is the Linux DMD version intended to be part of the 1.0 release?
Sep 03 2006
prev sibling next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Please stop teasing us with these silly questions. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 02 2006
prev sibling next sibling parent reply Gregor Richards <Richards codu.org> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Um, it ought to. I think you ought to branch. Branch off 1.0 with a feature freeze, and also an "experimental" new-features new-stuff branch. Rather than rejecting all new features, put them in the experimental branch. That branch then later becomes 1.1 or 2.0 (depending on how you choose to number, etc). That way, people who just want a stable software platform can choose 1.0, and those who live on the bleeding edge can choose the experimental branch. - Gregor Richards
Sep 02 2006
next sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Gregor Richards wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Um, it ought to. I think you ought to branch. Branch off 1.0 with a feature freeze, and also an "experimental" new-features new-stuff branch. Rather than rejecting all new features, put them in the experimental branch. That branch then later becomes 1.1 or 2.0 (depending on how you choose to number, etc). That way, people who just want a stable software platform can choose 1.0, and those who live on the bleeding edge can choose the experimental branch. - Gregor Richards
Make 1.1 the experimental branch, and save 1.2 for the next release branch. The same even/odd thing that the Linux kernel used to use. It worked well there, arguably better than the current approach. But think about the release numerations. If it's a string, then use 1.1.001 for the first experimental version. If it's a float, think about switching to a string. An alternate choice would be to consider it a struct with three fields (ubyte?) called: version, branch, and subversion.
Sep 02 2006
prev sibling parent Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Gregor Richards wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Um, it ought to. I think you ought to branch. Branch off 1.0 with a feature freeze, and also an "experimental" new-features new-stuff branch. Rather than rejecting all new features, put them in the experimental branch. That branch then later becomes 1.1 or 2.0 (depending on how you choose to number, etc). That way, people who just want a stable software platform can choose 1.0, and those who live on the bleeding edge can choose the experimental branch. - Gregor Richards
I agree. We don't want to stop getting new features just so that *other* people can have the "stable" version they've always wanted. I think there's nothing outstandingly wrong with DMD 0.166 that prevents it being RC 1.0. Cheers, Reiner
Sep 03 2006
prev sibling next sibling parent "Craig Black" <cblack ara.com> writes:
I agree with Gregor Richards about branching if you are chomping at the bit 
to add some hot new features.

However, IMO, the biggest problem I see with DMD in its current state is 
that IFTI is not finished yet.  Since IFTI will have such a large impact on 
library development, I think completing it should be high on the priority 
list.

-Craig 
Sep 02 2006
prev sibling next sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Why not: IFTI needs polish, array literals are just too valuable (although IFTI helps here too), Phobos needs a std.array (templatized!), need to resolve current enhancement/feature requests and suggestions -- aka, any new requests from "This Point" forward are tagged for the next release, but anything currently on the table needs to get resolved to one of "not going to happen", "will happen and here's how", or "deferred to next release because it just can't be done and here's why". -- Chris Nicholson-Sauls
Sep 02 2006
prev sibling next sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 03 2006
next sibling parent Stewart Gordon <smjg_1998 yahoo.com> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
I'm beginning to think it's just Walter's impatience showing. He wants to get 1.0 out sooner rather than later, so he keeps pushing us to let it happen. But it isn't going to happen. 1.0 time will come when it's ready. When both general and specific criteria are fulfilled. See also digitalmars.D.bugs:8272, "d1.0blocker - anyone at home?" Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 03 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
Sep 03 2006
next sibling parent reply Stewart Gordon <smjg_1998 yahoo.com> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
<snip>
 Something I've been wondering: "but nothing about calling it 1.0 will 
 prevent that from happening." But then what is the point of calling a 
 1.0 , will there be a branch or some other effect? Or it's just 
 marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
Then make some effort to debunk these impressions. Don't try to work around them. Moreover, just think about what will happen when people see 1.0 and expect to see a well-defined language specification, and maybe even to be ready to write a D compiler themselves. When they find themselves disappointed, just how bad will the negative image be, and how much work will it take to get rid of it? Moreover, how will compiler writers, and software houses wanting to adopt D, know when it's OK to come back? Yet another criterion to consider is that the language lives up to its claims. One of your claims is to make it likely that multiple, correct implementations will be available. This is impossible as long as the spec still has a number of ill-defined bits. OTOH, how many people have you counted who have dismissed D just because it isn't at 1.0? Did any of these people tell you that they would come back at 1.0 no matter what condition 1.0 is in? I'd be surprised. Stewart. -- -----BEGIN GEEK CODE BLOCK----- Version: 3.1 GCS/M d- s:- C++ a->--- UB P+ L E W++ N+++ o K- w++ O? M V? PS- PE- Y? PGP- t- 5? X? R b DI? D G e++++ h-- r-- !y ------END GEEK CODE BLOCK------ My e-mail is valid but not my primary mailbox. Please keep replies on the 'group where everyone may benefit.
Sep 03 2006
parent Walter Bright <newshound digitalmars.com> writes:
Stewart Gordon wrote:
 Walter Bright wrote:
 Bruno Medeiros wrote:
<snip>
 Something I've been wondering: "but nothing about calling it 1.0 will 
 prevent that from happening." But then what is the point of calling a 
 1.0 , will there be a branch or some other effect? Or it's just 
 marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
Then make some effort to debunk these impressions. Don't try to work around them.
I learned long ago that it is far easier to swim with the current than upstream, especially if one has very limited resources.
 Moreover, just think about what will happen when people see 1.0 and 
 expect to see a well-defined language specification, and maybe even to 
 be ready to write a D compiler themselves.  When they find themselves 
 disappointed, just how bad will the negative image be, and how much work 
 will it take to get rid of it?  Moreover, how will compiler writers, and 
 software houses wanting to adopt D, know when it's OK to come back?
The language spec doesn't need to be at the level of precision of the ISO specs (which took many years and the efforts of a couple dozen people) to produce. People have written compilers for languages with far less. The existence of a stable, reference compiler makes the difference, and these days, having an open source one is key.
 Yet another criterion to consider is that the language lives up to its 
 claims.  One of your claims is to make it likely that multiple, correct 
 implementations will be available.  This is impossible as long as the 
 spec still has a number of ill-defined bits.
No, it's not impossible at all. Heck, I've implemented many compilers for ill-defined languages (including C and C++). I agree the spec is far from perfect, but is it bad enough that it impedes the reasonable learning of D? I don't think so, as the D users do not seem to be having an unreasonable time learning it.
 OTOH, how many people have you counted who have dismissed D just because 
 it isn't at 1.0?
A lot. I don't have a count.
 Did any of these people tell you that they would come 
 back at 1.0 no matter what condition 1.0 is in?  I'd be surprised.
D is probably the most powerful language that ever was at 1.0.
Sep 03 2006
prev sibling next sibling parent reply Don Clugston <dac nospam.com.au> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Provided that the future plans for new syntax don't involve breaking lots of existing code, then I would say yes. I'm not yet convinced that this is true for the future RAII syntax (but I'm not convinced that it isn't true, either).
 Something I've been wondering: "but nothing about calling it 1.0 will 
 prevent that from happening." But then what is the point of calling a 
 1.0 , will there be a branch or some other effect? Or it's just 
 marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
It's a lot more than that. It means "this release is officially blessed for building libraries". Right now there are libraries which only work for (say) DMD 0.153 - 0.162, and others which only work for 0.148-0.155. 1.0 is an announcement that all existing libraries need to be updated, and that in the future, they won't be built against completely arbitrary versions.
Sep 04 2006
parent reply Sean Kelly <sean f4.ca> writes:
Don Clugston wrote:
 Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Provided that the future plans for new syntax don't involve breaking lots of existing code, then I would say yes. I'm not yet convinced that this is true for the future RAII syntax (but I'm not convinced that it isn't true, either).
Good point. Personally, I'd like to get the new syntax now, even if stack allocation doesn't occur until later. I think this means potentially dropping 'auto' from class declarations (so "auto class C {}" would be illegal) and making duplicate storage classes illegal for declarations (so "auto auto x = new MyClass()" would be illegal). Also: MyClass c = MyClass(); could convert to: MyClass c = new MyClass(); scope(exit) delete c; and: char[] b = char[32]; could convert to: char[] b = new char[32]; scope(exit) delete b; With the appropriate extensions for type inference as well. Alternately, alloca could be used for the allocations if that's possible. Sean
Sep 04 2006
parent Don Clugston <dac nospam.com.au> writes:
Sean Kelly wrote:
 Don Clugston wrote:
 Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Provided that the future plans for new syntax don't involve breaking lots of existing code, then I would say yes. I'm not yet convinced that this is true for the future RAII syntax (but I'm not convinced that it isn't true, either).
Good point. Personally, I'd like to get the new syntax now, even if stack allocation doesn't occur until later.
Me too. If we know that things in the future are going to break, we want to break them now if at all possible. I think this means
 potentially dropping 'auto' from class declarations (so "auto class C 
 {}" would be illegal) and making duplicate storage classes illegal for 
 declarations (so "auto auto x = new MyClass()" would be illegal).  Also:
 
     MyClass c = MyClass();
 
 could convert to:
 
     MyClass c = new MyClass();
     scope(exit) delete c;
 
 and:
 
     char[] b = char[32];
 
 could convert to:
 
     char[] b = new char[32];
     scope(exit) delete b;
 
 With the appropriate extensions for type inference as well. Alternately, 
 alloca could be used for the allocations if that's possible.
 
 
 Sean
Sep 04 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
This is almost OT, but for several Java coders I know, not being able to type new int[3][4][5] and new int[][] { { bibi(), bubu() }, { a+b, c+d } } made a _far_ worse first impression than the version number (as in, quote, "you're kidding, right?"). And it seems so simple to implement.. If you ask me, you really need to add those before going 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;) xs0
Sep 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:
 This is almost OT, but for several Java coders I know, not being able to 
 type
 
 new int[3][4][5]
 
 and
 
 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }
 
 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to implement.. 
 If you ask me, you really need to add those before going 1.0 (it's bad 
 enough for Javans that Interface[] is not Object[] ;)
My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change. We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use). I'd much rather work on the features the people who have *already* switched to D need to do outrageously cool things. You mean Java doesn't have free functions? No out parameters? No nested functions? No templates? No versioning? No operator overloading? No lazy evaluation? No 80 bit floats? No stack allocation? No structs? No array slicing? No direct access to C? You're kidding, right? <g>
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 xs0 wrote:
 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change.
Oh no, not the same old story.
 
 We can easily get sucked into a rat race trying to please people who 
 haven't the slightest inclination to use D (or any language other than 
 the one they currently use).
This sure wouldn't be a good thing, but...
 
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.
I have been programming in D for years and I love it. It is just great how D does arrays. Well, most of the time. We have such a great language that can do so many cool things with arrays. Yes but to be able to do something with an array you first have to create an array. And this task is incredibly difficult for such a basic thing in such a high level language. Creating arrays and filling them with data sucks in D (I am saying that as someone who is programming in D (although not as much as I would like to)). I didn't just switch to D and start complaining that this and that is missing, my complaints (and of other long time users) comes from actually *using* D.
 
 You mean Java doesn't have free functions? No out parameters? No nested 
 functions? No templates? No versioning? No operator overloading? No lazy 
 evaluation? No 80 bit floats? No stack allocation? No structs? No array 
 slicing? No direct access to C? You're kidding, right? <g>
D has dynamically resizable arrays, you can slice them, pass them around without no problems, add extension methods to them, but you can't initialize them? Who is kidding here? <g>
Sep 04 2006
parent Walter Bright <newshound digitalmars.com> writes:
Ivan Senji wrote:
 I didn't just switch to D and start complaining that this and that
 is missing, my complaints (and of other long time users) comes from 
 actually *using* D.
And so your suggestions are valuable, but I was responding to the post about first impressions from some Java users.
Sep 04 2006
prev sibling next sibling parent reply xs0 <xs0 xs0.com> writes:
Walter Bright wrote:
 xs0 wrote:
 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change. We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).
Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.
 You mean Java doesn't have free functions? No out parameters? No nested 
 functions? No templates? No versioning? No operator overloading? No lazy 
 evaluation? No 80 bit floats? No stack allocation? No structs? No array 
 slicing? No direct access to C? You're kidding, right? <g>
I 100% agree Java is lacking in many ways (and to be fair, it has some advantages, too), but if you're aiming for a good first impression, you also need to care of the basic stuff. The two things I mentioned seem so basic for a language with dynamic arrays, that I totally fail to understand why you're so reluctant to implement them; considering the unofficial wish list, I'm not the only one. Would you care for any language that (regardless of other features) made you type "return a+b" like this: accumulator foo; foo.add(a); foo.add(b); return foo.result; 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
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:
 Walter Bright wrote:
 xs0 wrote:
 This is almost OT, but for several Java coders I know, not being able 
 to type

 new int[3][4][5]

 and

 new int[][] {
    { bibi(), bubu() },
    { a+b, c+d }
 }

 made a _far_ worse first impression than the version number (as in, 
 quote, "you're kidding, right?"). And it seems so simple to 
 implement.. If you ask me, you really need to add those before going 
 1.0 (it's bad enough for Javans that Interface[] is not Object[] ;)
My experiences with people who won't use D because it doesn't have specific feature X is that they won't use it when feature X is implemented, or when Y, Z, A, B and C are implemented. They're used to the language they currently use, and will never change. We can easily get sucked into a rat race trying to please people who haven't the slightest inclination to use D (or any language other than the one they currently use).
Well, I somewhat disagree. My company is more or less strictly Java, but when I made a internal presentation on D, a surprising number of people showed up and most of them seemed genuinely interested/fascinated. So, I don't think it's the case that they don't have the slightest inclination to use something else.
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.
 You mean Java doesn't have free functions? No out parameters? No 
 nested functions? No templates? No versioning? No operator 
 overloading? No lazy evaluation? No 80 bit floats? No stack 
 allocation? No structs? No array slicing? No direct access to C? 
 You're kidding, right? <g>
I 100% agree Java is lacking in many ways (and to be fair, it has some advantages, too), but if you're aiming for a good first impression, you also need to care of the basic stuff. The two things I mentioned seem so basic for a language with dynamic arrays, that I totally fail to understand why you're so reluctant to implement them; considering the unofficial wish list, I'm not the only one. Would you care for any language that (regardless of other features) made you type "return a+b" like this: accumulator foo; foo.add(a); foo.add(b); return foo.result; Now, consider the remarkable similarity between that case and "auto foo = new int[3][4][5]" versus
Actually this works. But foo cannot be initialized with an initializer.
Sep 04 2006
parent reply xs0 <xs0 xs0.com> writes:
Ivan Senji wrote:
 xs0 wrote:
 Would you care for any 
 language that (regardless of other features) made you type "return 
 a+b" like this:

 accumulator foo;
 foo.add(a);
 foo.add(b);
 return foo.result;

 Now, consider the remarkable similarity between that case and "auto 
 foo = new int[3][4][5]" versus
Actually this works. But foo cannot be initialized with an initializer.
OK, that particular statement might work, but it doesn't do what you expect: int[][][] foo = new int[3][4][5]; results in arr.d(4): cannot implicitly convert expression (new int[3][4][](5)) of type int[3][4][] to int[][][] and more importantly, this doesn't work: int a=3, b=4, c=5; auto foo = new int[a][b][c]; produces arr.d(5): Integer constant expression expected instead of a arr.d(5): Integer constant expression expected instead of a arr.d(5): Integer constant expression expected instead of b arr.d(5): Integer constant expression expected instead of b xs0
Sep 04 2006
parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
xs0 wrote:
 Ivan Senji wrote:
 xs0 wrote:
 Would you care for any language that (regardless of other features) 
 made you type "return a+b" like this:

 accumulator foo;
 foo.add(a);
 foo.add(b);
 return foo.result;

 Now, consider the remarkable similarity between that case and "auto 
 foo = new int[3][4][5]" versus
Actually this works. But foo cannot be initialized with an initializer.
OK, that particular statement might work, but it doesn't do what you expect: int[][][] foo = new int[3][4][5]; results in arr.d(4): cannot implicitly convert expression (new int[3][4][](5)) of type int[3][4][] to int[][][] and more importantly, this doesn't work: int a=3, b=4, c=5; auto foo = new int[a][b][c];
Oops, now I remember that it doesn't work. I got my hopes up to soon :)
Sep 04 2006
prev sibling next sibling parent reply Walter Bright <newshound digitalmars.com> writes:
xs0 wrote:
 Well, I somewhat disagree. My company is more or less strictly Java, but 
 when I made a internal presentation on D, a surprising number of people 
 showed up and most of them seemed genuinely interested/fascinated. So, I 
 don't think it's the case that they don't have the slightest inclination 
 to use something else.
You clearly know the particular circumstances better than I. An interesting question is: why are they using Java, and why strictly?
Sep 04 2006
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
Walter Bright wrote:

 xs0 wrote:
 Well, I somewhat disagree. My company is more or less strictly Java, but
 when I made a internal presentation on D, a surprising number of people
 showed up and most of them seemed genuinely interested/fascinated. So, I
 don't think it's the case that they don't have the slightest inclination
 to use something else.
You clearly know the particular circumstances better than I. An interesting question is: why are they using Java, and why strictly?
guess also C++) get so large abundances of frameworks and libraries to work with, that investing time in other technologies either becomes counterproductive or just not feasible (or even necessary). Even if the Java solutions might not be perfect, you can get very far quickly by utilizing what's already there. -- Lars Ivar Igesund blog at http://larsivi.net DSource & #D: larsivi
Sep 04 2006
prev sibling parent reply xs0 <xs0 xs0.com> writes:
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
Sep 05 2006
parent Walter Bright <newshound digitalmars.com> writes:
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.
Sep 06 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
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
Sep 05 2006
prev sibling parent Charles D Hixson <charleshixsn earthlink.net> writes:
Walter Bright wrote:
...
 
 I'd much rather work on the features the people who have *already* 
 switched to D need to do outrageously cool things.
 ...
The only thing I can think of that D is missing is run-time specification of type, and that doesn't seem as if it would easily fit in with the rest of D. Possibly for D 2.0 *or* 3.0. What I would really *LIKE* is an interim way of connecting easily to Python or Ruby (either one!). Something like what Pyrex does for Python. (Yes, I know that's also an absurd request...but that might be handleable with a library. Perhaps.) What's needed now, as we approach RC1, is a DEPENDABLY STABLE language. That, and a big push on libraries. When I decide which language to use, libraries are generally the deciding point. (Not always...just recently is was the lack of run-time typing, but that's rarely an issue, and libraries are more significant.)
Sep 04 2006
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Walter Bright wrote:
 Bruno Medeiros wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) 
 wants more features, more improvements, etc., but nothing about 
 calling it 1.0 will prevent that from happening.
Something I've been wondering: "but nothing about calling it 1.0 will prevent that from happening." But then what is the point of calling a 1.0 , will there be a branch or some other effect? Or it's just marketing?
It's simply a stake in the ground. I want to get past the "it's not usable because it's not 1.0" first impressions people sometimes write.
I'm a bit at a loss. A given version can mean: "usable" - good enough to be used for actual work. "completed/finished" - all major known problems and changes have been resolved, as well as most of the minor ones. (it doesn't mean the program is final, there can be *new* additions of course.) So, you're not asking what D needs in order to be considered "completed/finished", but rather if D is "usable"? You're asking if D (.166) is usable? Or rather, are you asking if the "1.0" label should be used to mean that, rather than to mean "completed/finished"? -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 04 2006
prev sibling next sibling parent reply "BLS" <lietz wanadoo.fr> writes:
Hi Walter,
I think your question  should be dedicated to the library developers,
because :
D needs more stable libraries.
Library development needs a feature freeze so ask them what is needed to
create well designed long living libs. Implement it and name it 1.0.

Bjoern


"Walter Bright" <newshound digitalmars.com> schreef in bericht
news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me) wants
 more features, more improvements, etc., but nothing about calling it 1.0
 will prevent that from happening.
Sep 03 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:
 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.
 
 Bjoern
 
 
 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me) wants
 more features, more improvements, etc., but nothing about calling it 1.0
 will prevent that from happening.
/signed as a proposal Kris? Sean? -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
Hi Kyle,
Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
The answere is :Not at all ! What about . DWT, DTL, some not yet written
native libs, and of
course the Java to D stuff.
IMO Lib.-Development requires a lot of time. So wether Walter named 166
1.0 including a feature freeze, or  he decided to implement requested
features until 1.0, again feature freezed.

Bjoern

"Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
news:edea7q$2858$1 digitaldaemon.com...
 BLS wrote:
 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me)
wants
 more features, more improvements, etc., but nothing about calling it
1.0
 will prevent that from happening.
/signed as a proposal Kris? Sean? -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:
 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is me :
 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.
 
 Bjoern
 
 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...
 BLS wrote:
 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me)
wants
 more features, more improvements, etc., but nothing about calling it
1.0
 will prevent that from happening.
/signed as a proposal Kris? Sean? -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
I mentioned Kris and Sean since they have some of the most extensive, public, and mature library code in the D community, of course, this doesnt marginalize the voice of other library writers. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent reply "BLS" <lietz wanadoo.fr> writes:
Well Kyle.
D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
(Commercial) Success ->
 D-LanguageEvolution -> (loop)
So what do whe have  here : A  typical chaotic self-dynamic process.
(Feature Freeze !)
Bjoern



"Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
news:edeqqn$2mbb$1 digitaldaemon.com...
 BLS wrote:
 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is
me :
 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.

 Bjoern

 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...
 BLS wrote:
 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed
to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me)
wants
 more features, more improvements, etc., but nothing about calling it
1.0
 will prevent that from happening.
/signed as a proposal Kris? Sean? -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
I mentioned Kris and Sean since they have some of the most extensive, public, and mature library code in the D community, of course, this doesnt marginalize the voice of other library writers. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
parent Kyle Furlong <kylefurlong gmail.com> writes:
BLS wrote:
 Well Kyle.
 D-Language -> D-Libraries -> D-Tools -> D-DeveloperSatisfaction  ->
 D-RealWorldApplications  -> D-Application-EndUserSatisfaction ->
 (Commercial) Success ->
  D-LanguageEvolution -> (loop)
 So what do whe have  here : A  typical chaotic self-dynamic process.
 (Feature Freeze !)
 Bjoern
 
 
 
 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edeqqn$2mbb$1 digitaldaemon.com...
 BLS wrote:
 Hi Kyle,
 Sorry about my ignorance. Not sure to whom your reply belongs. If it is
me :
 The answere is :Not at all ! What about . DWT, DTL, some not yet written
 native libs, and of
 course the Java to D stuff.
 IMO Lib.-Development requires a lot of time. So wether Walter named 166
 1.0 including a feature freeze, or  he decided to implement requested
 features until 1.0, again feature freezed.

 Bjoern

 "Kyle Furlong" <kylefurlong gmail.com> schreef in bericht
 news:edea7q$2858$1 digitaldaemon.com...
 BLS wrote:
 Hi Walter,
 I think your question  should be dedicated to the library developers,
 because :
 D needs more stable libraries.
 Library development needs a feature freeze so ask them what is needed
to
 create well designed long living libs. Implement it and name it 1.0.

 Bjoern


 "Walter Bright" <newshound digitalmars.com> schreef in bericht
 news:edctpl$12jt$1 digitaldaemon.com...
 Any compelling reason why not? I know that everyone (including me)
wants
 more features, more improvements, etc., but nothing about calling it
1.0
 will prevent that from happening.
/signed as a proposal Kris? Sean? -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
I mentioned Kris and Sean since they have some of the most extensive, public, and mature library code in the D community, of course, this doesnt marginalize the voice of other library writers. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Nice break down, I believe it is time to move to the library building phase in earnest, so like you said, RC1 it is. -- Kyle Furlong // Physics Undergrad, UCSB "D is going wherever the D community wants it to go." - Walter Bright
Sep 03 2006
prev sibling next sibling parent Sean Kelly <sean f4.ca> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
I'm in favor of a spec feature freeze now and considering that 1.0. A few refinements may be worthwhile here and there, but I don't see the need for any actual new features at this point. Sean
Sep 03 2006
prev sibling next sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
Firstly, I don't think things like fancy delegates with functional programming are very important for 1.0. They are cool, but can wait. I see some things that should be implemented before RC1 for backwards compatibility reasons, like auto and constness. There is a way around that for the most part though: I would like to see an experimental branch before seeing an RC, sort of like Gregor suggested. Not a branch of the compiler, but a branch of the spec. Features that are not stable or not implemented yet would fall into this experimental branch. There would be a singular DMD that conforms to this spec, with the realization that any feature from the experimental part of the spec my change in the next release. Here are some things I'd expect to see in the experimental spec: - Lazy delegates // very new stuff - auto // due to auto auto, this will get changed sometime right? - array operators // not implemented yet - common func ptr/delegate syntax // not implemented yet - IFTI // not fully implemented - mixins // I've read complaints about the usability of mixins and so on... It may even be nice to have a couple phases of experimental spec, like an alpha spec and a beta spec. The alpha spec contains things that will most likely change, and the beta spec contains fairly stable features that are yet to be time-tested. This would allow 1.0 to roll out without some of those things I've listed being addressed. I don't think those features I've mentioned as experimental spec candidates are super important. The only reason we worry about some of these, like auto auto, are for backwards compatibility. But with an experimental system, coders are prewarned, and backwards compatibility isn't too worrisome. Still, something like constness still bugs me even with experimental spec, since it could change very basic things about the language. If 1.0 isn't a publicity thing, then disregard the below. These assume that many new programmers will be trying D when a 1.0 release happens, and will need impressing. Another big problem I see with RC1 - Access violation. If there is going to be a mob of people trying D at 1.0, then the compiler should behave nicely, and not produce programs that produce 'access violation'. This seems very tacky to me. It turns a 30 second code correction into a 10+ minute debugging session, ouch! At least put line numbers on those things. Bonus points for decent descriptions of what went wrong. Also related to mobs of people trying D at 1.0 - the spec needs going over with a fine tooth comb. This seems to be going on already, which is good. The spec's coolness would go up a few notches if there was a spec-only keyword search option. Do this *before* 1.0. Phobos. Maybe this can wait, but perhaps we should at least do some work to phobos' interface? Make sure the naming is consistent with the D style guidelines. It needs a *simple* way to read input from the console, and not some std.c.crap. Also, 'atoi' (in std.string) is a horrible name for a function that turns a string into an integer, and we have overloading now, unlike C back in the day, so make it 'toInt' (which exists in std.conv, so why the dupe?). This shouldn't be a big effort to expand phobos' functionality, just a time where we break everyone's code and deal with it so that future D programmers don't have to. Adopting another library like Ares as standard and tweaking on it should work too, though I see that as harder to pull off.
Sep 03 2006
parent Kristian <kjkilpi gmail.com> writes:
I agree.
Especially things that will/could break backward compability should be  
considered now. (Later these things are of course harder to change: 1) it  
cannot be done, 2) it'll break backward compability (e.g. 1.0 code doesn't  
compile with 1.1), and 3) old syntax (marked as obsolete) exists parallel  
with the new one.)

On Mon, 04 Sep 2006 00:01:27 +0300, Chad J  
<gamerChad _spamIsBad_gmail.com> wrote:
 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me)  
 wants more features, more improvements, etc., but nothing about calling  
 it 1.0 will prevent that from happening.
Firstly, I don't think things like fancy delegates with functional programming are very important for 1.0. They are cool, but can wait. I see some things that should be implemented before RC1 for backwards compatibility reasons, like auto and constness. There is a way around that for the most part though: I would like to see an experimental branch before seeing an RC, sort of like Gregor suggested. Not a branch of the compiler, but a branch of the spec. Features that are not stable or not implemented yet would fall into this experimental branch. There would be a singular DMD that conforms to this spec, with the realization that any feature from the experimental part of the spec my change in the next release. Here are some things I'd expect to see in the experimental spec: - Lazy delegates // very new stuff - auto // due to auto auto, this will get changed sometime right? - array operators // not implemented yet - common func ptr/delegate syntax // not implemented yet - IFTI // not fully implemented - mixins // I've read complaints about the usability of mixins and so on... It may even be nice to have a couple phases of experimental spec, like an alpha spec and a beta spec. The alpha spec contains things that will most likely change, and the beta spec contains fairly stable features that are yet to be time-tested. This would allow 1.0 to roll out without some of those things I've listed being addressed. I don't think those features I've mentioned as experimental spec candidates are super important. The only reason we worry about some of these, like auto auto, are for backwards compatibility. But with an experimental system, coders are prewarned, and backwards compatibility isn't too worrisome. Still, something like constness still bugs me even with experimental spec, since it could change very basic things about the language. If 1.0 isn't a publicity thing, then disregard the below. These assume that many new programmers will be trying D when a 1.0 release happens, and will need impressing. Another big problem I see with RC1 - Access violation. If there is going to be a mob of people trying D at 1.0, then the compiler should behave nicely, and not produce programs that produce 'access violation'. This seems very tacky to me. It turns a 30 second code correction into a 10+ minute debugging session, ouch! At least put line numbers on those things. Bonus points for decent descriptions of what went wrong. Also related to mobs of people trying D at 1.0 - the spec needs going over with a fine tooth comb. This seems to be going on already, which is good. The spec's coolness would go up a few notches if there was a spec-only keyword search option. Do this *before* 1.0. Phobos. Maybe this can wait, but perhaps we should at least do some work to phobos' interface? Make sure the naming is consistent with the D style guidelines. It needs a *simple* way to read input from the console, and not some std.c.crap. Also, 'atoi' (in std.string) is a horrible name for a function that turns a string into an integer, and we have overloading now, unlike C back in the day, so make it 'toInt' (which exists in std.conv, so why the dupe?). This shouldn't be a big effort to expand phobos' functionality, just a time where we break everyone's code and deal with it so that future D programmers don't have to. Adopting another library like Ares as standard and tweaking on it should work too, though I see that as harder to pull off.
Sep 03 2006
prev sibling next sibling parent Mikola Lysenko <mclysenk mtu.edu> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
I vote for fixing the current D language specification as "1.0," barring the discovery of some horrible ambiguity or logical inconsistency. Future changes should still be considered, but I think we need to go through a few rounds of clean up and bug fixing before we start mutating again. The language is still not as mature as C++ or Java, and it is only natural that it will need further revisions. That said, the compilers need to catch up. GDC is always bit behind, and DMD has several outstanding problems on Linux. Letting things cook for a few releases would settle this out and improve overall confidence. Also, this would put more attention on library development within the community, which is desperately needed. Phobos is still missing several key components such as a GUI and templated containers. What remains is not very trustworthy. The only two modules I feel comfortable using right now are std.stdio and std.math. The rest are highly suspect, especially std.thread. There needs to be much more critical attention toward the library and runtime, and less pointless bickering over what new features to include. In other words, it is time to stop worrying about what D should do, and time to discover what it can do.
Sep 03 2006
prev sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me) wants 
 more features, more improvements, etc., but nothing about calling it 1.0 
 will prevent that from happening.
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.
Sep 04 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
On Mon, 04 Sep 2006 14:32:54 +0300, Ivan Senji  =

<ivan.senji_REMOVE_ _THIS__gmail.com> wrote:

 Walter Bright wrote:
 Any compelling reason why not? I know that everyone (including me)  =
 wants more features, more improvements, etc., but nothing about calli=
ng =
 it 1.0 will prevent that from happening.
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 =3D 11;
      int opIndex(int pos){return xx;}
      int opIndexAssign(int what, int pos){return xx =3D what;}

      int prop(){return xx;}
      int prop(int newxx){return xx =3D newxx;}
    }

    auto a =3D 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 case=
s =
 to (and shouldn't be that hard to do):

 auto x =3D a[5];
    f(x);
 a[5] =3D x;

 auto y =3D a.prop;
    f(y);
 a.prop =3D 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.
Special, cool features are fine when making a good first expression. But= = basic stuff is the most important part of a language, IMHO. That's becau= se = you do basic stuff a lot. If something annoys you a little constantly, = it'll annoy you a lot after a while. (This is too harsh of an example, but if a cake looks delicious you may = = buy it, but if it doesn't taste good, you won't buy it again.)
Sep 04 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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).
Sep 04 2006
next sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
Hmm, I'm going to have to look into it a little bit further. I understand the potential problems with the compiler converting this. But isn't also a change from a field to a property that breaks existing code also a problem (maybe even a bigger one)? This has happened to me more than once. Inout means return a value through the param? I agree, but it is a limitation that it cannot be returned into property. The compiler could always issue a nice warning message if read or write property is missing.
 
 It's an error in C++ for the same reason (can't initialize a reference 
 with a non-const).
Sep 04 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
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. -- Derek Parnell Melbourne, Australia "Down with mediocrity!"
Sep 04 2006
next sibling parent reply Oskar Linde <oskar.lindeREM OVEgmail.com> writes:
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; } ? -- Oskar
Sep 04 2006
next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
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; } ?
I'm not a fan of the current property syntax either. I'd be very happy to see Walter implement get/set syntax, or some such. I just can't say this is a 1.0 issue though, unless it's going to be tough to rewrite code when it's changed. Are there plans to change this in the future?
Sep 04 2006
prev sibling parent Chris Nicholson-Sauls <ibisbasenji gmail.com> writes:
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
Sep 04 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 04 2006
next sibling parent reply Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
Hmm, inconsistent is: changing a field to a property -> some code doesn't need to change, some code needs to change. It seems that your mental model is that properties and the result of opIndex/opIndexAssign behaving like normal lvalues is the odd case? Well in my mental model them behaving like lvalues is a normal case, and the current behavior is a wtf. Actually I would like to know what this sentence of yours means: "If the user calls a function with a parameter that cannot accept such a return value, it is most likely a mistake." Does it mean if a property is passed that doesn't have a setter method? I would expect that to be reported at compile time as a nice "cannot pass read-only property as lvalue". 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)
Sep 04 2006
parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 04 2006
next sibling parent Derek Parnell <derek psyc.ward> writes:
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!"
Sep 04 2006
prev sibling parent Ivan Senji <ivan.senji_REMOVE_ _THIS__gmail.com> writes:
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.
Sep 04 2006
prev sibling parent reply Derek Parnell <derek psyc.ward> writes:
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. -- Derek Parnell Melbourne, Australia "Down with mediocrity!"
Sep 04 2006
next sibling parent Kristian <kjkilpi gmail.com> writes:
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.)
Sep 05 2006
prev sibling parent reply Walter Bright <newshound digitalmars.com> writes:
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.
Sep 05 2006
next sibling parent Ary Manzana <asterite gmail.com> writes:
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
Sep 05 2006
prev sibling parent Derek Parnell <derek psyc.ward> writes:
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!"
Sep 05 2006