www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Why there are no 'physical' object variables (only references)?

reply Kristian <kjkilpi gmail.com> writes:
I'm used for having both the variable types, 'physical' and  =

reference(/pointer) ones, so it feels strange to work with D (or Java,  =

etc) that have reference types only.

First, there is no way to copy/clone an object (in general). That is,  =

unless you provide a copy/clone function (for all the classes you're  =

using). Second, you cannot create classes that behave like basic types, =
 =

e.g. like integers.

For example, in C++ you could have:

void func() {
     Coord a, b, c;

     a.set(1, 2);
     b.set(5, 10);
     c =3D a + b;  //'c' is (6, 12)
     b =3D c;
     b.setX(2);  //'c' is unchanged, 'b' is (2, 12)
}

The 'Coord' objects have no 'global meaning' here, they are just simple =
 =

values used in calculations. (So there is no need to reference them from=
  =

other parts of the code.)

I think it's a big restriction if a language does not have both the  =

variable types (physical + references).
Why D and other similar languages have no physical types?


And, I hope that D will have a 'const' type specifier in the future. Now=
  =

you cannot know if a function will modify an object that is passed to it=
  =

as a parameter. Or if a member function of a class will change the  =

internal status of the object.

When these things are summed together, I'm afraid that I (at least) will=
  =

create a number of situations where the values of objects are incorrectl=
y  =

changed in almost any part of the code. Hopefully not, though.
Sep 10 2006
next sibling parent reply Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Kristian wrote:
 I'm used for having both the variable types, 'physical' and 
 reference(/pointer) ones, so it feels strange to work with D (or Java, 
 etc) that have reference types only.
 
 First, there is no way to copy/clone an object (in general). That is, 
 unless you provide a copy/clone function (for all the classes you're 
 using). Second, you cannot create classes that behave like basic types, 
 e.g. like integers.
 
 For example, in C++ you could have:
 
 void func() {
     Coord a, b, c;
 
     a.set(1, 2);
     b.set(5, 10);
     c = a + b;  //'c' is (6, 12)
     b = c;
     b.setX(2);  //'c' is unchanged, 'b' is (2, 12)
 }
 
 The 'Coord' objects have no 'global meaning' here, they are just simple 
 values used in calculations. (So there is no need to reference them from 
 other parts of the code.)
 
 I think it's a big restriction if a language does not have both the 
 variable types (physical + references).
 Why D and other similar languages have no physical types?

I think D structs are the "physical" variable type you're looking for. They allow everything above. The Coord type + minor modifications to your code for testing: struct Coord { int x,y; void set(int x_, int y_) { x = x_; y = y_; } void setX(int x_) { x = x_; } Coord opAdd(Coord c) { Coord ret; ret.x = x + c.x; ret.y = y + c.y; return ret; } } void main() { Coord a, b, c; a.set(1, 2); b.set(5, 10); c = a + b; //'c' is (6, 12) b = c; b.setX(2); //'c' is unchanged, 'b' is (2, 12) // Check everything worked as planned: assert(a.x == 1); assert(a.y == 2); assert(b.x == 2); assert(b.y == 12); assert(c.x == 6); assert(c.y == 12); } Runs without any asserts triggering. Of course that's just a minimal working type, not how one would typically write such a type. For one thing, either make x and y private and add setY, getX and getY or get rid of set and setX. For another, you'll probably want some more operators (equality, subtraction, maybe "multiply by scalar"). Not everything needs to be a class. I see no reason why a type like Coord would need inheritance.
 And, I hope that D will have a 'const' type specifier in the future. Now 
 you cannot know if a function will modify an object that is passed to it 
 as a parameter. Or if a member function of a class will change the 
 internal status of the object.

Yes, "const reference" parameters are something D doesn't do, unfortunately.
 When these things are summed together, I'm afraid that I (at least) will 
 create a number of situations where the values of objects are 
 incorrectly changed in almost any part of the code. Hopefully not, though.

Sep 10 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Sun, 10 Sep 2006 16:09:23 +0300, Frits van Bommel  
<fvbommel REMwOVExCAPSs.nl> wrote:
[snip]
  The 'Coord' objects have no 'global meaning' here, they are just  
 simple values used in calculations. (So there is no need to reference  
 them from other parts of the code.)
  I think it's a big restriction if a language does not have both the  
 variable types (physical + references).
 Why D and other similar languages have no physical types?

I think D structs are the "physical" variable type you're looking for. They allow everything above.

Ah, of course, basic types can be usually implemented as structures, thanks. :) Unfortunately some of the types have to be implemented as classes (e.g. a file class) because of the inheritance and/or constructors/destructors. Hmm, what if structures could have interfaces and constructors/destructors... and what the heck, inheritance too? Hehheh, this way we would have 'physical classes' for local use and 'reference classes' for global use. Or we could have a new data type instead: type Coord {...} //like a class except its objects do not use referencing That would be weird... or would it?
Sep 10 2006
next sibling parent reply Sean Kelly <sean f4.ca> writes:
Kristian wrote:
 
 Hmm, what if structures could have interfaces and 
 constructors/destructors... and what the heck, inheritance too? Hehheh, 
 this way we would have 'physical classes' for local use and 'reference 
 classes' for global use.

It will never happen :-) Though ctor support would be nice, at the very least. That would simplify initialization and eliminate the need for the static opCall trick. Sean
Sep 10 2006
parent reply BCS <BCS pathlink.com> writes:
Sean Kelly wrote:
 Kristian wrote:
 
 Hmm, what if structures could have interfaces and 
 constructors/destructors... and what the heck, inheritance too? 
 Hehheh, this way we would have 'physical classes' for local use and 
 'reference classes' for global use.

It will never happen :-) Though ctor support would be nice, at the very least. That would simplify initialization and eliminate the need for the static opCall trick. Sean

There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.
Sep 11 2006
parent reply Lionello Lunesu <lio lunesu.remove.com> writes:
BCS wrote:
 Sean Kelly wrote:
 Kristian wrote:

 Hmm, what if structures could have interfaces and 
 constructors/destructors... and what the heck, inheritance too? 
 Hehheh, this way we would have 'physical classes' for local use and 
 'reference classes' for global use.

It will never happen :-) Though ctor support would be nice, at the very least. That would simplify initialization and eliminate the need for the static opCall trick. Sean

There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.

Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size? L.
Sep 11 2006
parent reply BCS <BCS pathlink.com> writes:
Lionello Lunesu wrote:
 BCS wrote:
 
 Sean Kelly wrote:

 Kristian wrote:

 Hmm, what if structures could have interfaces and 
 constructors/destructors... and what the heck, inheritance too? 
 Hehheh, this way we would have 'physical classes' for local use and 
 'reference classes' for global use.

It will never happen :-) Though ctor support would be nice, at the very least. That would simplify initialization and eliminate the need for the static opCall trick. Sean

There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.

Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size? L.

the interface's function table can be found at compile time and all that is needed is to attach it to a reference to the struct.
Sep 12 2006
parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
BCS wrote:
 Lionello Lunesu wrote:
 BCS wrote:

 Sean Kelly wrote:

 Kristian wrote:

 Hmm, what if structures could have interfaces and 
 constructors/destructors... and what the heck, inheritance too? 
 Hehheh, this way we would have 'physical classes' for local use and 
 'reference classes' for global use.

It will never happen :-) Though ctor support would be nice, at the very least. That would simplify initialization and eliminate the need for the static opCall trick. Sean

There is no technical reason struct (or anything that can produce a delegate) can't do interfaces. Inheritance on the other hand... I hope that never happens.

Wouldn't it add a hidden __vtbl to your struct and thereby increasing its size? L.

the interface's function table can be found at compile time and all that is needed is to attach it to a reference to the struct.

Suppose you had this code: interface Foo { int foo(); } struct Bar : Foo { int foo() { ... } ... } void calc(Foo f) { ... } How can calc know the type of every struct it is passed unless a separate version of calc is generated for every type (in which case it is just a template)? Cheers, Reiner
Sep 12 2006
next sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 13 Sep 2006 06:33:19 +1000, Reiner Pope
<reiner.pope REMOVE.THIS.gmail.com> wrote:

interface Foo

struct Bar : Foo

void calc(Foo f) { ... }

How can calc know the type of every struct it is passed unless a 
separate version of calc is generated for every type (in which case it 
is just a template)?

Compiler generated proxy object, containing a vtable and a pointer to the struct. To pass the struct as an interface, you need some kind of reference anyway. You can't just pass the whole struct. A reference to a proxy object would make at least some sense. Mind you, it's very dodgy, to say the least. I have argued for struct inheritance, but this is not the kind of inheritance I want. I still want structs to be data, not reference-free objects. -- Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Steve Horne wrote:
 On Wed, 13 Sep 2006 06:33:19 +1000, Reiner Pope
 <reiner.pope REMOVE.THIS.gmail.com> wrote:
 
 interface Foo

 struct Bar : Foo

 void calc(Foo f) { ... }

 How can calc know the type of every struct it is passed unless a 
 separate version of calc is generated for every type (in which case it 
 is just a template)?

Compiler generated proxy object, containing a vtable and a pointer to the struct.

 Mind you, it's very dodgy, to say the least. I have argued for struct
 inheritance, but this is not the kind of inheritance I want.

requires class-like vtables, and once you've got that you've basically got a class, anyway. *Implementation* inheritance can be done using mixins. Of course, in D, implementation inheritance via mixins is a bit limited -- you can only mix in templates, not structs. I see no technical reason why you couldn't mix in any class, function, or struct that you have the source code for. This basically means implicitly templatizing whatever you want to mix in. Cheers, Reiner
Sep 13 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 13 Sep 2006 19:09:20 +1000, Reiner Pope
<reiner.pope REMOVE.THIS.gmail.com> wrote:

 Compiler generated proxy object, containing a vtable and a pointer to
 the struct.


Er - you'd have to write the class yourself?
 Mind you, it's very dodgy, to say the least. I have argued for struct
 inheritance, but this is not the kind of inheritance I want.


I never said I want interface support for structs. I just joined in a thread on someone elses idea. Just saying its possible - not that it's a good idea ;-) The struct inheritance I want allows structs to inherit from structs, adding a few extra data fields. What to do about methods, I don't know. I'm not comfortable with structs having methods anyway - a result of a style developed in C++ where the keywords 'struct' and 'class' tend to imply different things to programmers even though the compiler sees them the same. And I'm not all that fussed about struct inheritance either. Just can't leave things alone when people disagree with me ;-) -- Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
prev sibling parent BCS <BCS pathlink.com> writes:
Reiner Pope wrote:
 BCS wrote:
 

 No, because the type of a struct is always known, the required value 
 for the interface's function table can be found at compile time and 
 all that is needed is to attach it to a reference to the struct.

I don't understand you. How would it work? Suppose you had this code: interface Foo { int foo(); } struct Bar : Foo { int foo() { ... } ... }

If I understand it correctly interfaces variables are a fat pointer, sort of like a delegate. They could be implemented something like this: struct Interface { void* context; void*[] v_table; } When a class implements an interface it creates a static array containing pointers to it's methods. A reference to this array is placed in that classes v-table. When an interface instance is needed something like this is done: class C : Foo {...} C c = new C; Interface i; // set context i.context = c; // set v-table i.v_table = c.vtbl[C.Foo_index]; When an interface is used to call a method it ends up looking something like this (omitting a bunch of casts): i.v_table[Foo.foo_index](i.context); The only reason that the v-table for the interface is referenced by way of the v-table of the class is that the actual type of the class isn't known until run time. For a struct, that isn't the case, the type is always known. Their for, something like this can be done. Bar bar; // set context i.context = &bar; // set v-table i.v_table = Bar.Foo_vtbl]; this doesn't require any v-table in Foo
 void calc(Foo f) { ... }

 How can calc know the type of every struct it is passed unless a
 separate version of calc is generated for every type (in which case it
 is just a template)?

a function that uses an interface NEVER knowns the type of the underlying data. In fact the only way it ever uses it is by passing it as a context to one of the function accessed by way of the v-table referenced in the /interface/ this is analogous to a function taking a delegate not caring what the context of that delegate is.
 Cheers,

 Reiner

Sep 13 2006
prev sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sun, 10 Sep 2006 17:55:54 +0300, Kristian <kjkilpi gmail.com>
wrote:

Hmm, what if structures could have interfaces and  
constructors/destructors... and what the heck, inheritance too?

I've promissed myself that I'm not going to say anything else about struct inheritance, so I'm keeping quiet ;-) -- Remove 'wants' and 'nospam' from e-mail.
Sep 10 2006
prev sibling next sibling parent reply Sean Kelly <sean f4.ca> writes:
Kristian wrote:
 I'm used for having both the variable types, 'physical' and 
 reference(/pointer) ones, so it feels strange to work with D (or Java, 
 etc) that have reference types only.
 
 First, there is no way to copy/clone an object (in general). That is, 
 unless you provide a copy/clone function (for all the classes you're 
 using).

Yup. The .dup property is pretty standard, but there's no convention for whether this should represent deep or shallow copy (though shallow seems to make more sense).
 Second, you cannot create classes that behave like basic types,
 e.g. like integers.

True. You can get pretty close, but D does not support an assignment operator and there is no universal construction syntax as there is in C++. This was a deliberate decision, as handling copyable objects in C++ is a common source of bugs.
 For example, in C++ you could have:
 
 void func() {
     Coord a, b, c;
 
     a.set(1, 2);
     b.set(5, 10);
     c = a + b;  //'c' is (6, 12)
     b = c;
     b.setX(2);  //'c' is unchanged, 'b' is (2, 12)
 }
 
 The 'Coord' objects have no 'global meaning' here, they are just simple 
 values used in calculations. (So there is no need to reference them from 
 other parts of the code.)
 
 I think it's a big restriction if a language does not have both the 
 variable types (physical + references).
 Why D and other similar languages have no physical types?

Currently, you can use a struct or construct a class in place using alloca. Eventually, we will get a stack allocation syntax for classes along the lines of: Coord a = Coord(); // note there is no 'new' I also proposed an '.isizeof' property to return the instance size of a reference/pointer at compile-time, but there was little interest in the idea. However, it would allow you to do things like this: byte[Coord.isizeof] buf; // assume buf is properly aligned Coord a = new(&buf[0]) Coord();
 And, I hope that D will have a 'const' type specifier in the future. Now 
 you cannot know if a function will modify an object that is passed to it 
 as a parameter. Or if a member function of a class will change the 
 internal status of the object.

Don't we all. But wanting it and coming up with a solid proposal for how it should work are entirely different issues, unfortunately. Sean
Sep 10 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Sun, 10 Sep 2006 18:59:34 +0300, Sean Kelly <sean f4.ca> wrote:
 Kristian wrote:
  First, there is no way to copy/clone an object (in general). That is=


 unless you provide a copy/clone function (for all the classes you're =


 using).

Yup. The .dup property is pretty standard, but there's no convention =

 for whether this should represent deep or shallow copy (though shallow=

 seems to make more sense).

Maybe there should be two properties, .dup and .deepdup (or something, a name .ddup is probably too similar).
 True.  You can get pretty close, but D does not support an assignment
 operator and there is no universal construction syntax as there is in =

 C++.
 This was a deliberate decision, as handling copyable objects
 in C++ is a common source of bugs.

Really? I mean, a common source of bugs? But isn't it be simple to fix = such bugs, just correct the copy methods? With references there may be = bugs much harder to find: an object you're referencing is changed = somewhere you don't know. You may have to trace a lot of code to find = where the object gets modified, and correct things around the code, not = = just in one class. And what if you need copy/clone methods? You implement them by yourself = = (if there is no .deepdub). Using them is not so 'nice' because you can't= = override the assignment operator, etc. These copyable objects are still = 'a = source of bugs', even if used via references, of course. (And I have to also mention :) that nobody forces you to use copy method= s = in C++. You can use objects via pointers only. But why people don't? = Because copyable objects suit better in some situations.)
 Currently, you can use a struct or construct a class in place using  =

 alloca.  Eventually, we will get a stack allocation syntax for classes=

 along the lines of:

      Coord a =3D Coord(); // note there is no 'new'

Or maybe using a syntax (I have mentioned earlier): Coord a();
 And, I hope that D will have a 'const' type specifier in the future. =


 Now you cannot know if a function will modify an object that is passe=


 to it as a parameter. Or if a member function of a class will change =


 the internal status of the object.

Don't we all. But wanting it and coming up with a solid proposal for =

 how it should work are entirely different issues, unfortunately.

Well, what's wrong with the way C++ does it? class Obj { void f() const; void g(); int v; } void func(const Obj o) { o.f(); //ok o.g(); //error o.v =3D 1; //error }
Sep 10 2006
next sibling parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Kristian wrote:
 On Sun, 10 Sep 2006 18:59:34 +0300, Sean Kelly <sean f4.ca> wrote:
 Kristian wrote:
 And, I hope that D will have a 'const' type specifier in the future. 
 Now you cannot know if a function will modify an object that is 
 passed to it as a parameter. Or if a member function of a class will 
 change the internal status of the object.

Don't we all. But wanting it and coming up with a solid proposal for how it should work are entirely different issues, unfortunately.

Well, what's wrong with the way C++ does it? class Obj { void f() const; void g(); int v; } void func(const Obj o) { o.f(); //ok o.g(); //error o.v = 1; //error }

Do some searching for 'const' and 'readonly' on this NG, and you should get the idea: - C++ const is ugly, so people don't use it enough; - const_cast removes the safety guarantees of const, making const-directed optimizations by the compiler impossible. - overloading by const requires duplication of code. - a trivial const system like C++ is too strict and may require unnecessary clones to avoid a static const violation, thus necessitating the need for const_cast - reference immutability (C++'s 'readonly view') is only one form of const, and can't guarantee other (important) immutability contracts - after such a problems, the merits are not so clear, since the usefulness can only really be attributed to two things: 1. Standardising documentation of variable usage. 2. Getting the compiler to help catch programmer errors. and some people claim that they have never found any bugs by using const. Cheers, Reiner
Sep 10 2006
parent reply Kristian <kjkilpi gmail.com> writes:
On Sun, 10 Sep 2006 23:48:22 +0300, Reiner Pope  
<reiner.pope REMOVE.THIS.gmail.com> wrote:

 Kristian wrote:
 On Sun, 10 Sep 2006 18:59:34 +0300, Sean Kelly <sean f4.ca> wrote:
 Kristian wrote:
 And, I hope that D will have a 'const' type specifier in the future.




 Don't we all.  But wanting it and coming up with a solid proposal for  
 how it should work are entirely different issues, unfortunately.



 Do some searching for 'const' and 'readonly' on this NG, and you should  
 get the idea:
   - C++ const is ugly, so people don't use it enough;
   - const_cast removes the safety guarantees of const, making  
 const-directed optimizations by the compiler impossible.
   - overloading by const requires duplication of code.
   - a trivial const system like C++ is too strict and may require  
 unnecessary clones to avoid a static const violation, thus necessitating  
 the need for const_cast
   - reference immutability (C++'s 'readonly view') is only one form of  
 const, and can't guarantee other (important) immutability contracts
   - after such a problems, the merits are not so clear, since the  
 usefulness can only really be attributed to two things:
      1. Standardising documentation of variable usage.
      2. Getting the compiler to help catch programmer errors.
    and some people claim that they have never found any bugs by using  
 const.

There are a lot of talk about const/readonly/immutability in the archives. I have to admit that I don't have the strenght to read them, so I didn't (yet anyway). C++ const is better than nothing. Hopefully there will be a solution that will suit everybody, more or less. C++ const has flaws, of course. Sometimes it's necessary to do non-const-casting inside a const member function. But 'const' tells that a function is logically const even if it's not physically (statically?) one. So for a programmer it's only documentation tool that a compiler can use to check for (some) programming errors. And as such it has been working fine, for me at least. (I don't know what this C++ const ugliness means. 'const' is a wrong word, so I don't use it? ;) )
Sep 12 2006
parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 12 Sep 2006 17:49:44 +0300, Kristian <kjkilpi gmail.com>
wrote:

C++ const is better than nothing. Hopefully there will be a solution that  
will suit everybody, more or less.

As far as the meaning of 'const' goes, I agree. It represents a specific, restricted meaning of 'const'. Choosing a reasonable word for an intended meaning does not mean that all possible meanings of that word must be valid. If you're going to fuss about keyword meanings, I'd focus on 'real', 'ireal' and 'creal'. 'Real' cannot handle irrational numbers, and it can't handle rationals properly either. It does not handle all possible meanings of 'real' - not even within a given range and precision, unless you define those terms in a floating-point specific way. And as for 'imaginary real' and 'complex real', the important phrase here is 'contradiction in terms'. The keywords convey an intended meaning. It's a matter of common sense. Being too literal gets you no-where. Being an Aspie, I have plenty of experience of this :-( But I have mixed feelings about C++ const. It has caught errors for me, but not often, and quite often those errors wouldn't exist without 'const' anyway. For instance... class c_Test { private: int m_Var; public: // int Var () const { return m_Var; } int& Var () { return m_Var; } }; The point of this is the 'missing' method. You can read the value of m_Var if you have a non-const reference to c_Test. Mark that reference as const, and suddenly you can no longer do the needed read access - you have to go back and add the const overloaded access method. Of course I understand the efficiency benefits, but it's not very intuitive. And there wouldn't have been any error using simple getter and setter functions instead of this C++ specific pattern. What's more, you can end up chasing your tail. You start with a few const references. Then more and more things need a const tag or a const variant as a result. Member functions. References. Pointers. Member pointers. Pointers even need to be told whether it is the pointer that is const or the value pointed to, or both for that matter. So the dependencies mean you have three options... 1. Make constness into something you think about all the time. 2. Don't do constness at all. 3. Do half-hearted constness and have loads of const-casts, defeating the point. And then, your code has to work with someone elses... Someone who has a very different approach. Personally, I tend towards case 1 - I can be a perfectionist at times. Trouble is, this can be a distraction from the real logic. And that can cause logical errors that wouldn't have happened if my attention hadn't been split. D has been a bit of a relief, really. -- Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
parent reply Reiner Pope <reiner.pope REMOVE.THIS.gmail.com> writes:
Steve Horne wrote:
 On Tue, 12 Sep 2006 17:49:44 +0300, Kristian <kjkilpi gmail.com>
 wrote:
 
 C++ const is better than nothing. Hopefully there will be a solution that  
 will suit everybody, more or less.


only painless solution at the moment, I think. That, and switching to a pure functional language.
 
 But I have mixed feelings about C++ const. It has caught errors for
 me, but not often, and quite often those errors wouldn't exist without
 'const' anyway. 

 Of course I understand the efficiency benefits, but it's not very
 intuitive.

aliasing problem and the presence of const_cast. The main two reasons for const are catching errors and documenting code.
 Pointers even need to be told whether it is the pointer that is const
 or the value pointed to, or both for that matter.
 

naming system. const Fred const * p; is a bit excessive, don't you think? Not to mention very illegible. D's move to implicit reference semantics for classes means that we can get a generally-easier-to-read syntax, like is proposed in Javari: readonly final Fred p; where 'readonly' refers to the actual data, and 'final' means that p can't be used as an lval (ie, the pointer itself is const).
 So the dependencies mean you have three options...
 
 1.  Make constness into something you think about all the time.
 2.  Don't do constness at all.
 3.  Do half-hearted constness and have loads of const-casts,
     defeating the point.
 
 And then, your code has to work with someone elses... Someone who has
 a very different approach.

about const in D. As you have described, it becomes a real nuisance in C++, and the benefits are not always clear. Just giving a taste of the discussions of const on this newsgroup... <g> Cheers, Reiner
Sep 13 2006
next sibling parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Wed, 13 Sep 2006 19:02:27 +1000, Reiner Pope
<reiner.pope REMOVE.THIS.gmail.com> wrote:

 But I have mixed feelings about C++ const. It has caught errors for
 me, but not often, and quite often those errors wouldn't exist without
 'const' anyway. 


That's down to the definition of 'error', of course. Trying to call a non-const method for a const object is an error, by definition, in C++. The fact that you only wanted read a value is besides the point. Letter of the law vs. practical reality. Be careful what you say, or the language lawyers will come for you ;-) -- Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
prev sibling parent Kristian <kjkilpi gmail.com> writes:
On Wed, 13 Sep 2006 12:02:27 +0300, Reiner Pope  =

<reiner.pope REMOVE.THIS.gmail.com> wrote:
 Steve Horne wrote:

 Pointers even need to be told whether it is the pointer that is const=


 or the value pointed to, or both for that matter.


 naming system.

    const Fred const * p;

Yep, that one doesn't look nice. (And it's a bit confusing too.)
 is a bit excessive, don't you think? Not to mention very illegible. D'=

 move to implicit reference semantics for classes means that we can get=

   generally-easier-to-read syntax, like is proposed in Javari:

    readonly final Fred p;

 where 'readonly' refers to the actual data, and 'final' means that p  =

 can't be used as an lval (ie, the pointer itself is const).

That's indeed more readable. I woundn't mind using it or something simil= ar. From time to time I wish that C++ would have a readonly specifier that = = works like this: class Obj { void f() { int m_size =3D 10; //ok } readonly int m_size; } void func() { Obj o =3D new Obj; int v; v =3D o.m_size; //ok o.m_size =3D 5; //error } 'm_size' can be accessed inside 'Obj' as normal, but outside the class t= he = variable cannot be modified. Of course, I could provide a read property = = (that is, a function in C++) for accessing 'm_size' (in addition to a = write property), but when it's not necessary, this way is simplier (and = a = little bit faster, etc.). In D this, however, is not needed because you can use properties to wrap= = member variables. (Hopefully the properties will be extended to support the same methods = that can be applied to variables also... ;) )
Sep 14 2006
prev sibling parent reply Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Sun, 10 Sep 2006 22:03:43 +0300, Kristian <kjkilpi gmail.com>
wrote:

Maybe there should be two properties, .dup and .deepdup (or something,
a name .ddup is probably too similar).

How often is there more than one useful meaning for 'duplicate' for a particular class anyway? Shallow vs. deep vs. something in between is usually an implementation detail.
Really? I mean, a common source of bugs? But isn't it be simple to fix  
such bugs, just correct the copy methods?

I suspect this is about accidental copying. Parameter passing, implicit conversions, unexpected temporaries etc. I have an ideological disagreement against making references compulsory in a languages that has mutability (any imperitive language). You can easily get things being changed that weren't intended to be changed. You save info. for later, but the saved info. mutates because it wasn't a copy, for instance. In practice, it sometimes causes me hassles in Python, and probably would in Java if I used it much. But pragmatism beats ideology every time. In C# and D the implicit references work well, for me. There seems to be an intuitive divide between 'object' and 'value'. For a 'value', I expect parameter passing to have copy semantics. For an 'object' I expect sharing (reference) semantics. Maybe it's something to do with the real world. It's just natural to work with existing objects - not duplicates of those objects. When I was told to clean my room as a child, I don't think stories about duplicating the room, cleaning the duplicate and discarding it would have worked ;-) With 'values' - numbers etc - copy semantics seem more sane. In algebra, calculating the unknowns does not alter the known values. Outputs are based on inputs, not the other way around. Even feedback has a time delay - the calculation of the output doesn't change its input, it just provides a new input for the next millisecond or whatever. The trouble is, this is all subjective. The Python one-size-fits-all everythings-an-object-with-a-reference approach will probably always bug me, but a lot depends on what you're used to. -- Remove 'wants' and 'nospam' from e-mail.
Sep 10 2006
next sibling parent reply Lutger <lutger.blijdestijn gmail.com> writes:
Steve Horne wrote:
  > But pragmatism beats ideology every time. In C# and D the implicit
 references work well, for me. There seems to be an intuitive divide
 between 'object' and 'value'. For a 'value', I expect parameter
 passing to have copy semantics. For an 'object' I expect sharing
 (reference) semantics.
 
 Maybe it's something to do with the real world. It's just natural to
 work with existing objects - not duplicates of those objects. When I
 was told to clean my room as a child, I don't think stories about
 duplicating the room, cleaning the duplicate and discarding it would
 have worked ;-)
 
 With 'values' - numbers etc - copy semantics seem more sane. In
 algebra, calculating the unknowns does not alter the known values.
 Outputs are based on inputs, not the other way around. Even feedback
 has a time delay - the calculation of the output doesn't change its
 input, it just provides a new input for the next millisecond or
 whatever.

Well said. I needed some time to adjust to the reference semantics of classes in D and it's less (than C++) capable struct type. But now I'm used to it, it really makes sense. Besides some minor details, in C++ a struct is the same as a class. But in D they really are different beasts, making the distinction and when to use which one easier. In C++ you have to think all the time about reference vs value semantics and take care of what happens in the assignment operator and copy constructor, and not only wrt memory allocation. Even though you don't have the standard syntactic sugar of struct construction and copying in D, the way it works now is intuitive enough and - imho - makes for a more productive and safe way of doing things. Assignment can be a dangerous operation and in D you can be sure of what happens at least.
Sep 11 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Mon, 11 Sep 2006 12:51:12 +0200, Lutger
<lutger.blijdestijn gmail.com> wrote:

Well said. I needed some time to adjust to the reference semantics of 
classes in D and it's less (than C++) capable struct type. But now I'm 
used to it, it really makes sense.

Yeah, I'm still adjusting too. Too used to being able to use inheritance to create extended structs in C++. Less bothered by having references for objects because I've done that before, but I still don't like having a tool taken out of my toolkit ;-) In code I'm writing at the moment, it's an issue, but a minor one. D has saved probably ten or more units of effort for this one that it has created. So while I made the relevant suggestions and defended them, it's probably not a big deal IMO. At the moment, I'm having trouble with interfaces. I can't seem to get the right patterns for using them. This is one of the things with a new language. Picking up the new syntax and semantics may not seem that hard, but putting it to work in a real project can be a pain - you end up in a refactoring loop, chasing your own tail until you find the patterns that work in that language. Even though I've use C# enough times that I thought I'd have no problems with D, the C# stuff I've done was pretty small stuff really. -- Remove 'wants' and 'nospam' from e-mail.
Sep 11 2006
prev sibling next sibling parent Kristian <kjkilpi gmail.com> writes:
On Mon, 11 Sep 2006 01:23:38 +0300, Steve Horne  
<stephenwantshornenospam100 aol.com> wrote:
[snip]
 Really? I mean, a common source of bugs? But isn't it be simple to fix
 such bugs, just correct the copy methods?

I suspect this is about accidental copying. Parameter passing, implicit conversions, unexpected temporaries etc.

Yes, these things could cause harm. I have had a few incidents with unxcepted temporaries (only few fortunately). [snip]
 Maybe it's something to do with the real world. It's just natural to
 work with existing objects - not duplicates of those objects. When I
 was told to clean my room as a child, I don't think stories about
 duplicating the room, cleaning the duplicate and discarding it would
 have worked ;-)

 With 'values' - numbers etc - copy semantics seem more sane. In
 algebra, calculating the unknowns does not alter the known values.
 Outputs are based on inputs, not the other way around. Even feedback
 has a time delay - the calculation of the output doesn't change its
 input, it just provides a new input for the next millisecond or
 whatever.

 The trouble is, this is all subjective. The Python one-size-fits-all
 everythings-an-object-with-a-reference approach will probably always
 bug me, but a lot depends on what you're used to.

Well said. Usually (I think/hope) objects are 'unique' with no need to copy them. You just have to adjust your thinking. However, sometimes 'working objects' are needed in calculations. But, as said, structures are for that. I am just wondering that should structures indeed have constructors and destructors. It would allow one to create more complex data types. Probably interfaces wouldn't hurt either. And another thing that I have no clear grasp yet is unability to copy/clone class objects. For example: class Obj; void func(Obj obj) { Obj tmp; tmp.clone(obj); //modify 'tmp' ... //use 'tmp' instead of 'obj' ... } Or you just need to store objects for later use. These things cannot be done currently. How often that would be necessary, in practice? (Once is enough to give you gray hair...?)
Sep 12 2006
prev sibling parent reply Tydr Schnubbis <fake address.dude> writes:
Steve Horne wrote:
 The trouble is, this is all subjective. The Python one-size-fits-all
 everythings-an-object-with-a-reference approach will probably always
 bug me, but a lot depends on what you're used to.
 

Not sure I follow. Python uses value semantics for numbers and strings. The reason you get them for strings is that strings are immutable, so Python always creates a copy when a string is about to be changed. So it works like in D, except for the strings.
Sep 12 2006
parent Steve Horne <stephenwantshornenospam100 aol.com> writes:
On Tue, 12 Sep 2006 23:33:39 +0200, Tydr Schnubbis <fake address.dude>
wrote:

Steve Horne wrote:
 The trouble is, this is all subjective. The Python one-size-fits-all
 everythings-an-object-with-a-reference approach will probably always
 bug me, but a lot depends on what you're used to.
 

Not sure I follow. Python uses value semantics for numbers and strings. The reason you get them for strings is that strings are immutable, so Python always creates a copy when a string is about to be changed. So it works like in D, except for the strings.

Sorry - I had a specific problem recently and got a bit annoyed and irrational. I've enough Python experience that I shouldn't have got confused this way, but I haven't used Python seriously for long enough that I did anyway :-( Everything is an object with a reference. Some things are immutable, so it shouldn't matter. But...
 a=5
 b=lambda :a
 b()



 a=6
 b()



According to the definition of a closure, the lambda should bind the value of a. It can't bind a link to the variable, since the variable might not exist when the lambda is evaluated. Yet there is clearly some kind of by-reference binding, or else why does assigning a new value to 'a' cause 'b' to give a different result. So why the above? Well, maybe a minor bug. Maybe a command-line-only thing. I haven't investigated. I was only using Python as a calculator when I tripped over the problem. D behaves similarly with anonymous functions and delegates, but that's because D inner functions etc don't support 'true' closures. In fact, D anonymous delegates aren't even valid after you leave the scope where they were defined. But that's not unexpected - a different convenience vs. efficiency trade-off. Python closures are supposed to be true closures. -- Remove 'wants' and 'nospam' from e-mail.
Sep 13 2006
prev sibling parent reply Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Kristian wrote:
 ...

Those "physical types", are called value types. -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Sep 22 2006
parent Kristian <kjkilpi gmail.com> writes:
On Sat, 23 Sep 2006 00:35:07 +0300, Bruno Medeiros  
<brunodomedeiros+spam com.gmail> wrote:

 Kristian wrote:
  > ...

 Those "physical types", are called value types.

Hehheh, so they are. Sometimes it's just too hard to come up with the correct term... ;)
Sep 23 2006