Object is Evil

[Joe \Nuke Me Xemu\ Foster]

We all know Variant, VB Classic's closest equivalent to VB.NET's
Object, is evil, so why is VB.NET's Object somehow a good idea?
Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
If you don't want to hear it from .NOTs, perhaps you'll hear it
from a Published Authority:

'More than a decade ago, the C++ community decided that "cosmic"
hierarchies (architectures in which every object type is derived
from a root class, usually called Object) were not an effective
design approach in C++. There were a number of reasons for
rejecting this approach, both on the design and implementation
level. From a design standpoint, cosmic hierarchies often give
rise to generic containers of "objects." The contents of the
containers are often unpredictable and lead to unexpected runtime
behavior. Stroustrup's classic counterexample considered the
possibility of putting a battleship in a pencil holder-something
that a cosmic hierarchy would allow, but that would probably
surprise a user of the pencil holder.' -- Stephen C. Dewhurst,
http://joopmag.com/html/from_pages/crarticle.asp?ID=626

"Who?" http://semantics.org/instructorbio.html

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <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!

[Jonathan Allen]

> We all know Variant, VB Classic's closest equivalent to VB.NET's
> Object, is evil, so why is VB.NET's Object somehow a good idea?

So how would you deal with a situation in which the type of the incoming
data is not known in advance?

--
Jonathan Allen


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3bbe57bf@news.devx.com...
> We all know Variant, VB Classic's closest equivalent to VB.NET's
> Object, is evil, so why is VB.NET's Object somehow a good idea?
> Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
> If you don't want to hear it from .NOTs, perhaps you'll hear it
> from a Published Authority:
>
> 'More than a decade ago, the C++ community decided that "cosmic"
> hierarchies (architectures in which every object type is derived
> from a root class, usually called Object) were not an effective
> design approach in C++. There were a number of reasons for
> rejecting this approach, both on the design and implementation
> level. From a design standpoint, cosmic hierarchies often give
> rise to generic containers of "objects." The contents of the
> containers are often unpredictable and lead to unexpected runtime
> behavior. Stroustrup's classic counterexample considered the
> possibility of putting a battleship in a pencil holder-something
> that a cosmic hierarchy would allow, but that would probably
> surprise a user of the pencil holder.' -- Stephen C. Dewhurst,
> http://joopmag.com/html/from_pages/crarticle.asp?ID=626
>
> "Who?" http://semantics.org/instructorbio.html
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Got Thetans?
<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!
>
>

[Jay Glynn]

The idea would be that you should never be in that situation. Now having
said that I'll be the first to say that isn't always easy to do. The
alternative is to either use overloads or templates (generics). My comment
to Joe would be that I don't think anyone is recommending that you make
averything an object (even though everything is derived from object) much
like you don't make everything a variant.

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3bbe5f1e@news.devx.com...
> > We all know Variant, VB Classic's closest equivalent to VB.NET's
> > Object, is evil, so why is VB.NET's Object somehow a good idea?
>
> So how would you deal with a situation in which the type of the incoming
> data is not known in advance?
>
> --
> Jonathan Allen
>

[Jonathan Allen]

> The
> alternative is to either use overloads or templates (generics).

That won't help, as both require you to know the data type in advance.

--
Jonathan Allen


"Jay Glynn" <jlsglynn@hotmail.com> wrote in message
news:3bbe6aa3$1@news.devx.com...
> The idea would be that you should never be in that situation. Now having
> said that I'll be the first to say that isn't always easy to do. The
> alternative is to either use overloads or templates (generics). My comment
> to Joe would be that I don't think anyone is recommending that you make
> averything an object (even though everything is derived from object) much
> like you don't make everything a variant.
>
> "Jonathan Allen" <greywolf@cts.com> wrote in message
> news:3bbe5f1e@news.devx.com...
> > > We all know Variant, VB Classic's closest equivalent to VB.NET's
> > > Object, is evil, so why is VB.NET's Object somehow a good idea?
> >
> > So how would you deal with a situation in which the type of the incoming
> > data is not known in advance?
> >
> > --
> > Jonathan Allen
> >
>
>
>

[Jay Glynn]

I understand that, but the point is that you should never be in that
position anyway. And yes I know that isn't always possible hence the
**limited** use of object.

"Jonathan Allen" <greywolf@cts.com> wrote in message
news:3bbe7bd2@news.devx.com...
> > The
> > alternative is to either use overloads or templates (generics).
>
> That won't help, as both require you to know the data type in advance.
>
> --
> Jonathan Allen
>
>

[Joe \Nuke Me Xemu\ Foster]

"Jonathan Allen" <greywolf@cts.com> wrote in message <news:3bbe5f1e@news.devx.com>...

> > We all know Variant, VB Classic's closest equivalent to VB.NET's
> > Object, is evil, so why is VB.NET's Object somehow a good idea?
>
> So how would you deal with a situation in which the type of the incoming
> data is not known in advance?

You design an architecture! Read the **** link, will ya? Sheesh!

--
Joe Foster <mailto:jlfoster%40znet.com> Got Thetans? <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!

[Joe \Nuke Me Xemu\ Foster]

"Jay Glynn" <jlsglynn@hotmail.com> wrote in message <news:3bbeeb24@news.devx.com>...

> I understand that, but the point is that you should never be in that
> position anyway. And yes I know that isn't always possible hence the
> **limited** use of object.

Perhaps for a "generic" container, since Basic lacks templates, but then
you need to wrap it in another class to do type-checking. Instead of
working with Collection or Dictionary directly, work with PencilHolder
or BattleshipCollection, each of which HAS-A (not IS-A) Collection.

--
Joe Foster <mailto:jlfoster%40znet.com> On the cans? <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!

[Jonathan Allen]

> You design an architecture! Read the **** link, will ya? Sheesh!

That isn't always possible. What if the object is stored in a queue or
database?

Normally you would write...

Dim MyObject as MyClass
MyObject = Source.GetObject()

How would you write that without using an Object type? Keep in mind that the
Source object represents a commercial DB or Queuing System, so it can't
include every possible type.

--
Jonathan Allen


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3bbf1f8f@news.devx.com...
> "Jonathan Allen" <greywolf@cts.com> wrote in message
<news:3bbe5f1e@news.devx.com>...
>
> > > We all know Variant, VB Classic's closest equivalent to VB.NET's
> > > Object, is evil, so why is VB.NET's Object somehow a good idea?
> >
> > So how would you deal with a situation in which the type of the incoming
> > data is not known in advance?
>
> You design an architecture! Read the **** link, will ya? Sheesh!
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Got Thetans?
<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!
>
>

[Ronald Laeremans [MSFT]]

Hi Joe,

In the simplest possible way I can put this:

MI and no single rooted tree inheritance system, is the most powerful and
flexible design. (C++, Eiffel)
SI and a single rooted inheritance tree, trades some power and flexibility
for simplicity (.NET)
ZI does much more of that trading (VB 6 and below)

> were not an effective design approach in C++
Maybe you read over the "in C++" part of this.

There is a valid point here somewhere about library design as it applies to
..NET that you are failing to make. I'll let you discover it by yourself.

-Ronald-

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3bbe57bf@news.devx.com...
> We all know Variant, VB Classic's closest equivalent to VB.NET's
> Object, is evil, so why is VB.NET's Object somehow a good idea?
> Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
> If you don't want to hear it from .NOTs, perhaps you'll hear it
> from a Published Authority:
>
> 'More than a decade ago, the C++ community decided that "cosmic"
> hierarchies (architectures in which every object type is derived
> from a root class, usually called Object) were not an effective
> design approach in C++. There were a number of reasons for
> rejecting this approach, both on the design and implementation
> level. From a design standpoint, cosmic hierarchies often give
> rise to generic containers of "objects." The contents of the
> containers are often unpredictable and lead to unexpected runtime
> behavior. Stroustrup's classic counterexample considered the
> possibility of putting a battleship in a pencil holder-something
> that a cosmic hierarchy would allow, but that would probably
> surprise a user of the pencil holder.' -- Stephen C. Dewhurst,
> http://joopmag.com/html/from_pages/crarticle.asp?ID=626
>
> "Who?" http://semantics.org/instructorbio.html
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Got Thetans?
<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!
>
>

[Patrice Scribe]

IMO, the interest of this design is to allow some code to treat objects
about which it has no knowledge. It is probably more interesting at a
technical level for general processing such as serialization (not familiar
yet but I believe it uses either the ISerializable interface or uses default
serialization instead) that needs to be able to process all
objects.

In your own code, I see little use for this. Usually you'll want to keep
type safety and use instead the lowest possible class in a hierarchy (such
as a Ship class to handle BattleShip or MerchantShip) or you could use a
particular interface such as IShip if something else can behave as a ship.

Exactly as the presence of variants doesn't have any consequence (I just
never used them), I don't expect to use the "Object" class but it is still
good IMO to have this ability if you (or the writer of a technical
component) ever come accross something that would require being able to
treat all kind of objects...

Patrice

"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> a écrit dans le message news:
3bbe57bf@news.devx.com...
> We all know Variant, VB Classic's closest equivalent to VB.NET's
> Object, is evil, so why is VB.NET's Object somehow a good idea?
> Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
> If you don't want to hear it from .NOTs, perhaps you'll hear it
> from a Published Authority:
>
> 'More than a decade ago, the C++ community decided that "cosmic"
> hierarchies (architectures in which every object type is derived
> from a root class, usually called Object) were not an effective
> design approach in C++. There were a number of reasons for
> rejecting this approach, both on the design and implementation
> level. From a design standpoint, cosmic hierarchies often give
> rise to generic containers of "objects." The contents of the
> containers are often unpredictable and lead to unexpected runtime
> behavior. Stroustrup's classic counterexample considered the
> possibility of putting a battleship in a pencil holder-something
> that a cosmic hierarchy would allow, but that would probably
> surprise a user of the pencil holder.' -- Stephen C. Dewhurst,
> http://joopmag.com/html/from_pages/crarticle.asp?ID=626
>
> "Who?" http://semantics.org/instructorbio.html
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Got Thetans?
<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!
>
>

[Willy Van den Driessche]

I agree with you Patrice.
I have written a little component in VB6 that uses 3 interfaces :

Interface iComparer
function Compare (ByVal varFirst as Variant, ByVal varSecond as Variant) as
long

interface ISortableContainer
Property Get Count () As Long
Property Get Item (ByVal nPos As Long) As Variant
Sub Swap (ByVal nPosFrom As Long, ByVal nPosTo as Long

Interface ISortAlgorithm
Sub SortContainer( ByVal objContainer As iSortableContainer, ByVal
objComparer As iComparer)

(article is at http://users.skynet.be/wvdd2/Sorting/sorting.html)
Using "Object", I could rewrite the component in .NET so that it uses Object
wherever there is now "Variant". For the working of my component, however
these "Object"s are merely passed to methods of other classes. Unless for
default implementations of this interface I never even care to know what is
in them. So this basically means that "void *" would have done just as
fine.

Since these "Variants/Objects" really denote the elementtype in the
container, I could have introduced a Marker Interface IElementType to use
instead of Object. The price for this is high : I am no longer able to use
built-in objects. They need the marker interface so I would have to wrap
them (Adapter). Wrapping elements in a container is something I cannot do,
because the SortableContainer interface is deliberately chosen so that it
only defines the operations needed for sorting. (there is not Set Item
method)

This being said, I must say that from a purist point of view, Object has
some bizar methods : equals, gethashCode(for some reason a function instead
of a property) and tostring. Now I know that these methods are used inside
the class libraries. But why favor these 3 functions over any other -
equally useful functions ? Why doesn't the design of the class libraries
show us a design that deals with requirements explicitly ? Put otherwise,
why don't they put other methods in as well (P.e. why not put the methods of
MarshalByRef in as well ?). Put yet otherwise : the designers of the .NET
class libraries have an unfair advantage over designers of additional class
libraries. They got to choose the methods for Object. Let's face it : what
does it mean - semantically - to have a hashcode for an Array - for an
Employee ?

Wouldn't the design have been more daring if Object was just a marker
interface ?
--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html

[Zane Thomas]

Joe,

>We all know Variant, VB Classic's closest equivalent to VB.NET's
>Object, is evil, so why is VB.NET's Object somehow a good idea?

Apart from the other posts which point out flaws in your pronouncement
your comparing Object with Variant is wrong on its face and obviously so.

If you wanted to look for an *appropriate* comparison then you would have
to say that the .net platform's Object is somewhat similar to IUnknown.
Except that you would then have to face the fact that Object.Net supports
more functionality than Object.OLE. And of course unless you're willing
say that the use of COM objects in VB6 is Evil then you are pretty much
SOL when it comes to having anything coherent to say on the topic.

>Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
>If you don't want to hear it from .NOTs, perhaps you'll hear it
>from a Published Authority:

Oooh, an Appeal To Authority falacy. Gotta love it. Btw, since I wrote
half of one of the best selling vb books of all time and a lot of another
and numerous articles I guess I'm a Published Authority when it comes to
VB and so ... you should STF up and listen to what I say, eh?


--
The nice thing about standards is that
there are so many of them to choose from.

[Michael Culley]

I would not say the variant is evil. It is an extremely useful tool that has
its appropriate uses. Would you recommend that recorset.fields("abc").value
be anything other than a variant?


"Joe "Nuke Me Xemu" Foster" <joe@bftsi0.UUCP> wrote in message
news:3bbe57bf@news.devx.com...
> We all know Variant, VB Classic's closest equivalent to VB.NET's
> Object, is evil, so why is VB.NET's Object somehow a good idea?
> Sorry, in C++, it sucked, and it's going to suck in VB.NET too.
> If you don't want to hear it from .NOTs, perhaps you'll hear it
> from a Published Authority:
>
> 'More than a decade ago, the C++ community decided that "cosmic"
> hierarchies (architectures in which every object type is derived
> from a root class, usually called Object) were not an effective
> design approach in C++. There were a number of reasons for
> rejecting this approach, both on the design and implementation
> level. From a design standpoint, cosmic hierarchies often give
> rise to generic containers of "objects." The contents of the
> containers are often unpredictable and lead to unexpected runtime
> behavior. Stroustrup's classic counterexample considered the
> possibility of putting a battleship in a pencil holder-something
> that a cosmic hierarchy would allow, but that would probably
> surprise a user of the pencil holder.' -- Stephen C. Dewhurst,
> http://joopmag.com/html/from_pages/crarticle.asp?ID=626
>
> "Who?" http://semantics.org/instructorbio.html
>
> --
> Joe Foster <mailto:jlfoster%40znet.com> Got Thetans?
<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!
>
>

[Gregor R. Peisker]

Hi Joe,

> Perhaps for a "generic" container, since Basic lacks templates, but then
> you need to wrap it in another class to do type-checking. Instead of
> working with Collection or Dictionary directly, work with PencilHolder
> or BattleshipCollection, each of which HAS-A (not IS-A) Collection.

Why would that be? I prefer strongly-typed collections as well, but those can
very well BE-A Collection (that is, have a common ancestor class), provided that
both the base class does not expose members like "Item" or "Add", and that the
implementation is appropriate. This doesn't rule out other techniques, such as
delegation (or an interface-based approch), but you do have other choices (in
..NET anyway).

Gregor

[Willy Van den Driessche]

> If you wanted to look for an *appropriate* comparison then you would have
> to say that the .net platform's Object is somewhat similar to IUnknown.
> Except that you would then have to face the fact that Object.Net supports
> more functionality than Object.OLE. And of course unless you're willing
> say that the use of COM objects in VB6 is Evil then you are pretty much
> SOL when it comes to having anything coherent to say on the topic.

But IUnknown is a small *interface* while object is a large *class*. If
object would have been an interface, it would have made a whole lot of
difference. And COM is a lotcleaner when it comes to versioning than a
class hierarchy which will invariantly suffer from the fragile base class
problem.

--
Van den Driessche Willy
For a work in progress :
http://users.skynet.be/wvdd2/index.html