|
![](/i/fill.gif) |
Warp wrote:
> Darren New <dne### [at] san rr com> 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
|
![](/i/fill.gif) |