Re: OO: Threat or Menace? (was: Re: OO fans bashing Joins)

In article <sd55n5st7f282_at_corp.supernews.com>, "Joe \"Nuke Me Xemu\" Foster" <jfoster_at_ricochet.net> wrote:
> "topmind" <topmindNOtoSPAM_at_technologist.com.invalid> wrote in message
 news:05684040.d97411a2_at_usw-ex0104-033.remarq.com...
>
> > In article <sd3g1n909n44_at_corp.supernews.com>, "Joe \"Nuke Me
> > Xemu\" Foster" <joe_at_bftsi0.UUCP> wrote:
> > >"topmind" <topmindNOtoSPAM_at_technologist.com.invalid> wrote in
 message news:0110ea04.187c7858_at_usw-ex0104-031.remarq.com...
> > >
> > >> >> You're not listening. I said it was people thing rather
 than
> > >> a technological thing. <<
 

> > >> So you are admitting that procedural/relational programming
 can
> > >> be just a reuse friendly as OO?
> > >
> > >If it was designed with reuse in mind, sure. OO may make it
 easier, just as
> > >it often helps make larger projects more manageable.
 

> > What about small and medium projects? Should app builders for
> > them be burdened by constructs meant for mostly larger projects?
>
> I see what you mean here. I'm afraid I've been looking at this from a
> C++ish perspective, in which avoiding overhead for unused features is
> supposedly a priority. This is also true of the "Object Assist" add-in
> for VB 4 and 5 (but apparently not 6 =( ). If you don't use it, you
 don't
> get the overhead.
>

I was thinking more about developer misuse and confusion rather than CPU speed.
> > >> >> Oh, but those are the ones are coming from the decidedly
> > >> wrong paradigm of procedural programming. It's harder to play
> > >> the song correctly if you've first learned to play it
> > >> incorrectly or have picked up bad habits. :) <<
 

> > >> Yeah, whatever. OO is an annoying fad the belongs only in
> > >> specific niches. All those stupid animal and shape examples do
> > >> not translate into real world benefits, they only sell the
 crap
> > >> to naive PHB's who like a good story.
> > >
> > >The bank account example strikes me as being useful and
 relevant. Each type
> > >of bank account inherits from a generic bank account type, and
 methods can
> > >be overridden depending on how each type of account, say,
 generates interest,
> > >finance charges, etc. etc.
 

> > Boy, did you pick the wrong example!
 

> > Please see:
> > http://www.geocities.com/tablizer/bank.htm
 

> > Here is a quote from it:
 

> > "In the middle of Andrew's example it suddenly occurred to me
> > that I once had a bank account that had both checks and
> > interest! ...This issue highlights a typical problem with
> > inheritance. Changes and variations rarely follow a hierarchical
> > pattern in the real world. Both marketing and management would
> > much rather view the customer banking plans as combinations of
> > features rather than a hierarchy. "
>
> Multiple inheritance? This is needed for things C where C is both an A
> *and* a B, but neither A nor B is an ancestor of the other. However,
 this
> brings in the whole "Multiple Inheritance: Threat or Menace" debate...
>
But why not view those as attributes instead of multiple hierarchical taxonomies? (I suspect most OO fans would use some funky "pattern" instead of multiple-inheritance anyhow.)
> --
> Joe Foster <mailto:jfoster_at_ricochet.net> Space Cooties!
 <http://www.xenu.net/>
> WARNING: I cannot be held responsible for the above They're coming to
> because my cats have apparently learned to type. take me away, ha ha!
>
>
-tmind-

Sent via Deja.com http://www.deja.com/
Before you buy. Received on Mon Mar 20 2000 - 00:00:00 CET