Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> It doesn't make sense for a numerical *instance* to be read-write. When you 
>> say a = b + c, you're not modifying b or c or the old value of a. You're 
>> replacing what's in 'a' with a new value.
> 
>   By that definition no language ever modifies any variable.

Not true.

class customer {
   public: int age; string name;
    void setage(int newage) { this.age = newage; }
}
customer fred;
fred.setage(23);
fred.setage(17);

You definitely change fred twice there. You replaced the value of fred.age, 
but in so doing changed the value of fred.

If you're using java and you say

customer fred = new customer();
fred.setage(23);
customer barney = fred;
writeln(barney.age);
fred.setage(17);
writeln(barney.age);

you're going to get two different outputs for barney's age. In C++ (as 
written) you won't, because the assignment to barney isn't an assignment of 
identity but an assignment of value.

>> My point is that if you do
>> a = 5; b = a; a = 7;
>> you're not changing the value in b.
> 
>   Of course you are. You are changing it to 5.

Right. You're not changing the value in b when you assign 7 to a.

>> If you do
>> a = "  hello   ";  b = a;  a.trim();
>> are you changing the value in b?
> 
>   Depends on the semantics of the type.

That's my point. I can't think of any class where you'd realistically want 
to choose on a variable-by-variable basis or a value-by-value basis. 
Certainly not when doing DDD. Maybe when doing scientific stuff it's more 
common?

It just doesn't seem like the right way to do OOD, because to me you either 
have a class that represents an entity (and thus has an identity and thus 
makes no sense to copy and thus must be shared via references) or you have a 
class that represents a value (and thus must be read-only if shared, and 
hence if the object is much bigger than a pointer it might reasonably save 
space to represent it that way, a la "flyweight" pattern).

In this case, a raw string obviously doesn't represent an entity in the real 
world, so the answer *should* be "you don't change b".

>>>> Unless your compiler is smart enough to ditch the vptr (or its equivalent) 
>>>> when you put the pixel into an array-of-pixels
>>>   Why do you think I like C++?
> 
>> Really?  You can have a pixel with virtual functions, and then the vptr goes 
>> away when you assign it into an array?
> 
>   No. I can have a pixel with no vptr, and I can store such pixels in an
> array. Unlike in many other languages.

Oh, OK. To me, conflating encapsulation with class with inheritance is a 
"bad" thing to do in OOD. It leads to having things like classes *and* 
namespaces, or to "friend" functions and "friend" classes, etc.

Actually, it seems to me that in C++ if you're going to allow "stripping" an 
instance to its superclass, you should be able to get rid of the vptr in the 
case that you're not operating thru a pointer or reference. I didn't think 
the language currently works that way and you confirmed that, but it seems 
like it might be a space savings, as you say.

But, as I tried to say, if you're modeling the real world via OO, having 
nothing but references isn't much of a problem. It's certainly not a problem 
if you have classes that are either value classes or reference classes, and 
you can't pick on a variable-by-variable basis which it is. (I.e., it 
shouldn't be a problem to have value classes to which you can't take an 
explicit pointer. C++-style references are of course still useful for 
pass-by-reference type stuff if the language doesn't otherwise support 
pass-by-reference.)

-- 
   Darren New, San Diego CA, USA (PST)
   There's no CD like OCD, there's no CD I knoooow!

Post a reply to this message