Object is Evil


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 1 of 4 123 ... LastLast
Results 1 to 15 of 52

Thread: Object is Evil

  1. #1
    Joe \Nuke Me Xemu\ Foster Guest

    Object is Evil

    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!



  2. #2
    Jonathan Allen Guest

    Re: Object is Evil

    > 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!
    >
    >




  3. #3
    Jay Glynn Guest

    Re: Object is Evil

    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
    >





  4. #4
    Jonathan Allen Guest

    Re: Object is Evil

    > 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
    > >

    >
    >
    >




  5. #5
    Jay Glynn Guest

    Re: Object is Evil

    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
    >
    >





  6. #6
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Object is Evil

    "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!



  7. #7
    Joe \Nuke Me Xemu\ Foster Guest

    Re: Object is Evil

    "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!



  8. #8
    Jonathan Allen Guest

    Re: Object is Evil

    > 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!
    >
    >




  9. #9
    Ronald Laeremans [MSFT] Guest

    Re: Object is Evil

    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!
    >
    >




  10. #10
    Patrice Scribe Guest

    Re: Object is Evil

    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!
    >
    >






  11. #11
    Willy Van den Driessche Guest

    Re: Object is Evil

    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



  12. #12
    Zane Thomas Guest

    Re: Object is Evil

    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.

  13. #13
    Michael Culley Guest

    Re: Object is Evil

    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!
    >
    >






  14. #14
    Gregor R. Peisker Guest

    Re: Object is Evil

    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



  15. #15
    Willy Van den Driessche Guest

    Re: Object is Evil


    > 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



Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
HTML5 Development Center
 
 
FAQ
Latest Articles
Java
.NET
XML
Database
Enterprise
Questions? Contact us.
C++
Web Development
Wireless
Latest Tips
Open Source


   Development Centers

   -- Android Development Center
   -- Cloud Development Project Center
   -- HTML5 Development Center
   -- Windows Mobile Development Center