In article jdege@jdege.visi.com, jdege@jdege.visi.com (Jeffrey C. Dege) writes:
>On 18 Feb 97 03:19:43 GMT, Bill Seurer <seurer@rchland.ibm.com> wrote:
>>
>>Suppose you had a whole bunch of these "become" things.  When the compiler
>>reaches the "B.SomeMethod()" point how can it check if that is a valid
>>statement?  Would it have to keep track of all the becomes and look
>>through all of them to make sure that every type had a SomeMethod method
>>and the same data layout?
>
>Forget all of that.  Suppose, for example, the compiler _could_
>automagically change an object from one type to another.  It'd _still_
>be a bad idea.  If your object model involves objects changing type,
>you've got a bad object model.

Actually, that isn't quite it.

Some OO languages support only reference semantics and fully dynamic
typing. In that case an object can (seem to) become a different type
or become a different object of the same type. Probably the original
poster had experience with such a language.

C++ supports also value semantics and static typing, and thus does
not support the notion of an object becoming something else. In C++
you use polymorphism via reference semantics explicitly (references
or pointers) to get the effect.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]