D - [Properties] Design bug?
- Manfred Nowak (22/22) Jan 28 2004 Look at this code:
- Walter (5/25) Jan 29 2004 I once proposed using .sizeof for the size property, which while not a
- Matthew (5/35) Jan 29 2004 is
- Walter (5/7) Jan 29 2004 Leaving
- Matthew (6/13) Jan 29 2004 Nah. We're pre 1.0.
- Sean L. Palmer (7/22) Jan 29 2004 Yah... there's enough accidental breakage, that a little intentional
- J Anderson (8/47) Jan 30 2004 If it's going to be broken, it would be helpful to have a list of
- Sean L. Palmer (4/16) Jan 30 2004 Sounds like a great idea.
- Manfred Nowak (10/15) Jan 30 2004 Using `sizeof' is useful for porting C to D.
- Andy Friesen (7/21) Jan 30 2004 Since D now has the typeof() construct, D could just disallow making
- Manfred Nowak (10/11) Jan 30 2004 [...]
- Andy Friesen (10/15) Jan 30 2004 Right. That's already valid D, though, so it's not a big deal.
- Manfred Nowak (45/54) Jan 30 2004 Upps. It is not only valid D. It causes an error to write`typeof(int)'.
Look at this code: void main(){ C c=new C; printf("%u %u\n", c.size, c.f.size); } If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C': class C{ struct data{ real value; int size; } data d; public data f(){ return d; } public int size(){return 0;} } Shouldn't the properties of the standard types be turned into keywords? So long.
Jan 28 2004
"Manfred Nowak" <svv1999 hotmail.com> wrote in message news:bva9np$bnb$1 digitaldaemon.com...Look at this code: void main(){ C c=new C; printf("%u %u\n", c.size, c.f.size); } If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C': class C{ struct data{ real value; int size; } data d; public data f(){ return d; } public int size(){return 0;} } Shouldn't the properties of the standard types be turned into keywords?I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. It is implemented, you can use .sizeof instead.
Jan 29 2004
"Walter" <walter digitalmars.com> wrote in message news:bvblhh$2lpc$3 digitaldaemon.com..."Manfred Nowak" <svv1999 hotmail.com> wrote in message news:bva9np$bnb$1 digitaldaemon.com...isLook at this code: void main(){ C c=new C; printf("%u %u\n", c.size, c.f.size); } If you think, that sizes, i.e. byte allocations, of `c' and `c.f' are evaluated and printed, then you are wrong, because this is the code for `C': class C{ struct data{ real value; int size; } data d; public data f(){ return d; } public int size(){return 0;} } Shouldn't the properties of the standard types be turned into keywords?I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. Itimplemented, you can use .sizeof instead.I knew that. I also thought .size had been dropped. Is that not so? Leaving it in seems to be asking for trouble
Jan 29 2004
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvc11u$851$1 digitaldaemon.com...I knew that. I also thought .size had been dropped. Is that not so?Leavingit in seems to be asking for troublePerhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
Jan 29 2004
Nah. We're pre 1.0. Break away! Anyone complains, and I'll fight em with ya :) "Walter" <walter digitalmars.com> wrote in message news:bvcd8g$rp1$3 digitaldaemon.com..."Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvc11u$851$1 digitaldaemon.com...I knew that. I also thought .size had been dropped. Is that not so?Leavingit in seems to be asking for troublePerhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
Jan 29 2004
Yah... there's enough accidental breakage, that a little intentional breakage (for a good cause!) won't be a problem. I'd much rather break things now, and have a clean language later, than keep everything working now and have a cluttered language later. Sean "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvcdg8$s4t$1 digitaldaemon.com...Nah. We're pre 1.0. Break away! Anyone complains, and I'll fight em with ya :) "Walter" <walter digitalmars.com> wrote in message news:bvcd8g$rp1$3 digitaldaemon.com..."Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvc11u$851$1 digitaldaemon.com...I knew that. I also thought .size had been dropped. Is that not so?Leavingit in seems to be asking for troublePerhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
Jan 29 2004
Sean L. Palmer wrote:Yah... there's enough accidental breakage, that a little intentional breakage (for a good cause!) won't be a problem. I'd much rather break things now, and have a clean language later, than keep everything working now and have a cluttered language later. Sean "Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvcdg8$s4t$1 digitaldaemon.com...If it's going to be broken, it would be helpful to have a list of "broken" things on the website. That would include the op operators. This makes it easier for newbie's to fix old D programs. I know there's the change log, but often it's not explanative enough (where does it say that all operators have op added to the front?). -- -Anderson: http://badmama.com.au/~anderson/Nah. We're pre 1.0. Break away! Anyone complains, and I'll fight em with ya :) "Walter" <walter digitalmars.com> wrote in message news:bvcd8g$rp1$3 digitaldaemon.com..."Matthew" <matthew.hat stlsoft.dot.org> wrote in message news:bvc11u$851$1 digitaldaemon.com...I knew that. I also thought .size had been dropped. Is that not so?Leavingit in seems to be asking for troublePerhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
Jan 30 2004
Sounds like a great idea. Sean "J Anderson" <REMOVEanderson badmama.com.au> wrote in message news:bvd77u$2896$1 digitaldaemon.com...Sean L. Palmer wrote:Yah... there's enough accidental breakage, that a little intentional breakage (for a good cause!) won't be a problem. I'd much rather break things now, and have a clean language later, than keep everything working now and have a cluttered language later. SeanIf it's going to be broken, it would be helpful to have a list of "broken" things on the website. That would include the op operators. This makes it easier for newbie's to fix old D programs. I know there's the change log, but often it's not explanative enough (where does it say that all operators have op added to the front?).
Jan 30 2004
Walter wrote:Using `sizeof' is useful for porting C to D. However, take the example and change every `size' to `sizeof'. What is the reason to allow class designers to override the semantic of standard properties? In phobos, stream.d `size' is used for the standard types. Is there a good argument, that `sizeof' will never be used in a library for a derived type? Why is `sizeof' a keyword in C? So long.Shouldn't the properties of the standard types be turned into keywords?I once proposed using .sizeof for the size property, which while not a keyword in D, *is* a keyword in C and hence won't be in any C structs. It is implemented, you can use .sizeof instead.
Jan 30 2004
Manfred Nowak wrote:Using `sizeof' is useful for porting C to D. However, take the example and change every `size' to `sizeof'. What is the reason to allow class designers to override the semantic of standard properties? In phobos, stream.d `size' is used for the standard types. Is there a good argument, that `sizeof' will never be used in a library for a derived type? Why is `sizeof' a keyword in C? So long.Since D now has the typeof() construct, D could just disallow making these properties a member of instances, and instead make them strictly properties of the type. foo.size would cease to be 'magic'; we have typeof(foo).size. (which is arguably clearer anyway) Crisis averted. :) -- andy
Jan 30 2004
Andy Friesen wrote:Since D now has the typeof() construct, D could just disallow[...] That is a good one. The standard properties should be only reachable via `typeof()'. This prevents the need to disallow the names of standard properties in derived types or to make them keywords. And because it is somehow inconvenient to write `typeof(int).sizeof' syntactic sugar for the types `T' predeclard with keywords should be given, to write `T.sizeof', i.e. `int.sizeof'. So long.
Jan 30 2004
Manfred Nowak wrote:... because it is somehow inconvenient to write `typeof(int).sizeof' syntactic sugar for the types `T' predeclard with keywords should be given, to write `T.sizeof', i.e. `int.sizeof'.Right. That's already valid D, though, so it's not a big deal. ie int a; int.size; // good typeof(a).size; // good a.size; // bad The only remaining issue, of course, is types that have static attributes or methods whose names coincide with the builtins. -- andy
Jan 30 2004
Andy Friesen wrote:Upps. It is not only valid D. It causes an error to write`typeof(int)'. And I meant to type `T.sizeof' only when `T' is represented by its keyword.to write `T.sizeof', i.e. `int.sizeof'.Right. That's already valid D, though, so it's not a big deal.ie int a; int.size; // good typeof(a).size; // good a.size; // badIn this case I would like dmd to create: | test.d(4): use 'typeof(a).size' to access standard propertyThe only remaining issue, of course, is types that have static attributes or methods whose names coincide with the builtins.Why is that an issue? If and only if the values of standard properties can be accessed trough `typeof()', whilst non standard properties can only be accessed directly, there is no problem at all. I.e.: class Foo { static int sizeof() { return 6; } int size() { return 7; } } class Bar { int value() { return 8; } } void main(){ int i; Foo f= new Foo; Bar b= new Bar; i=Foo.sizeof; // produces 6 //i=Foo.size; // error: no 'this' for non-static member functions //i=Bar.sizeof; // error: use 'typeof(Bar).sizeof' to access // standard property i=f.sizeof; // produces 6 i=f.size; // produces 7 //i=b.sizeof; // error: use 'typeof(b).sizeof' to access standard // property i=b.value // produces 8 i=typeof(Foo).sizeof; // produces the value of the named property i=typeof(Foo).size; // " (currently) i=typeof(Bar).sizeof; // " //i=typeof(Bar).value;// error: no standard property 'value' for // expression 'Bar' i=typeof(f).sizeof; // produces the value of the named property i=typeof(f).size; // " (currently) i=typeof(b).sizeof; // " //i=typeof(b).value; // error: no standard property 'value' for // expression 'b' } Note: the so called properties of Classes and Structs currently can not be accessed through `typeof()'. So its also not a big deal. So long.
Jan 30 2004