www.digitalmars.com         C & C++   DMDScript  

D - [Properties] Design bug?

reply Manfred Nowak <svv1999 hotmail.com> writes:
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
parent reply "Walter" <walter digitalmars.com> writes:
"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
next sibling parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
"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...
 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

 implemented, 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
parent reply "Walter" <walter digitalmars.com> writes:
"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?

 it in seems to be asking for trouble

Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.
Jan 29 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
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?

 it in seems to be asking for trouble

Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.

Jan 29 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
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?

 it in seems to be asking for trouble

Perhaps it's best to leave it as 'deprecated' for the moment, to avoid breaking existing code.


Jan 29 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
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...
  

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?
        

it in seems to be asking for trouble
        

breaking existing code.



"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/
Jan 30 2004
parent "Sean L. Palmer" <palmer.sean verizon.net> writes:
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.

Sean


 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?).

Jan 30 2004
prev sibling parent reply Manfred Nowak <svv1999 hotmail.com> writes:
Walter wrote:

 Shouldn't the properties of the standard types be turned into
 keywords? 

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.

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.
Jan 30 2004
parent reply Andy Friesen <andy ikagames.com> writes:
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
parent reply Manfred Nowak <svv1999 hotmail.com> writes:
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
parent reply Andy Friesen <andy ikagames.com> writes:
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
parent Manfred Nowak <svv1999 hotmail.com> writes:
Andy Friesen wrote:

 to write `T.sizeof', i.e. `int.sizeof'. 


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.
 ie
     int a;
     int.size;          // good
     typeof(a).size; // good
     a.size;         // bad

In this case I would like dmd to create: | test.d(4): use 'typeof(a).size' to access standard property
 The 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