Re: Lahman, how ya doing?

In article <bv6je.8995$_f7.1506@trndny01>,
H. S. Lahman <hsl@xxxxxxxxxxxxxxxxx> wrote:
>Responding to Hansen...
>
>> So it's not just me! I've been starting to notice that C++ seems to make
>> it harder than it has to be to do things that must be common in OOP.
>
>C++ is generally regarded as the most technically deficient of the
>popular OOPLs. A major reason was the that performance and low-level
>machine control were primary design objective. That results in a lot of
>compromises. Given the design goal, it is not bad. However, the prices
>one pays are that a higher skill is required to use it properly and
>there are a lot more opportunities for foot-shooting.
>
>
>> It
>> didn't take me long to realize that a generic pointer can only hold any
>> variety of classes if they were all derived from a single base class
>> (e.g. the recipient of an event, or the object to read data from), but
>> you can't invoke methods unique to a derived class with a pointer to the
>> base class. I suppose there's dynamic typecasting techniques to get
>> around that, but it just seemed easier to let my base class keep
>> accumulating virtual member functions as derived classes gained their own
>> functions.
>
>Actually C++ provides dynamic_cast for this. It exists as a mechanism
>to deal with an external stream of arbitrary objects where one needs to
>determine the nature of the object in hand to access its specializations.

I played with dynamic_cast a little and didn't really seem to get the
results that I wanted. And every single pointer would have a dynamic_cast
next to it, anyway. So I just went with the dullard's approach.

As I've been working on this problem I quickly started flipping through
pages at the back of my C++ text, making immediate use of some of the more
advanced concepts. It was an information blitz, a bit overwhelming, so
I've been trying to keep it a little simpler where I could.

>
>However, I regard that as one of C++'s deficiencies because too many
>people abuse it to navigate from superclass to subclass during routine
>collaborations. Subclassing relationships are not navigable for
>collaboration because there is only one instance in hand to navigate.
>
>If one needs to access the subclass specializations (and the object is
>not supplied externally), then there should already be a direct
>relationship path to the subclass that can be navigated. That path will
>provide type safety and whatnot. If that relationship is not properly
>implemented and instantiated, then that is a design fault.

I'll pick up one of the more OOPy languages eventually. But for now I'll
just stick with C++, that's what I know.

By the way, what do you think of exceptions. Some people really like
them. I get a little confused.

--
"Not that there's anything wrong with just lying around on your back. In
its way, rotting is interesing too... It's just that there are other ways
to spend your time as a cadaver." -- Mary Roach, "Stiff", 2003.
.

Relevant Pages

  • Re: Lahman, how ya doing?
    ... A major reason was the that performance and low-level machine control were primary design objective. ... didn't take me long to realize that a generic pointer can only hold any variety of classes if they were all derived from a single base class, but you can't invoke methods unique to a derived class with a pointer to the base class. ... I regard that as one of C++'s deficiencies because too many people abuse it to navigate from superclass to subclass during routine collaborations. ...
    (comp.object)
  • Re: MustInherit in Window forms
    ... and it'll be run if the SUBCLASS implementor chooses not to implement ... much depends on whether your base class is usable itself: ... > DisconnectFromAbrServer() method there, and it'll be run if the base class ... > implementor chooses not to implement a custom version of the method. ...
    (microsoft.public.dotnet.languages.vb)
  • Re: using dict for data attributes instead of self
    ... >So why does he wants a dictionary-like base class if he never uses any ... (IMO that __setitem__ subclass override trick is not a good substitute ... BTW, the above was probably written before you could subclass the builtin dict, but now ... A subclass could use lists as additional ways to store info if needed. ...
    (comp.lang.python)
  • Re: Convenience constructors and non-final setters
    ... any subclass has no choice than use ... functionality, the base class might be better off as an interface. ... ColoredCartPoint and ColoredPolarPoint concrete subclasses that implement ...
    (comp.lang.java.programmer)
  • Re: Fat Interface vs. Type Switch
    ... this sort of design often reflects a more subtle design ... It can be used to effectively navigate a subclassing ... > subclass specializations. ... Suppose I query a server for trades that satisfy the criteria of some ...
    (comp.object)