Re: I'm amazed(The answer)


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Results 1 to 12 of 12

Thread: Re: I'm amazed(The answer)

  1. #1
    Blob Guest

    Re: I'm amazed(The answer)


    "David Bayley" <dbayley@spamless.aebacus.com> wrote:
    >Blob wrote:
    >
    >>> What you meant to say was "single *implementation* inheritance", but
    >>> seeing as you are newsgroup scum, I forgive you :-p
    >>>

    >> Oh jesus. another one. Man, everyone else even knew that in this VB
    >> group.

    >
    >Just like everyone in this *VB* group knows that "Inheritance" is the
    >terminology used to implicitly refer to "Implementation-Inheritance".

    It does? Hmm. Wow. ok if you say so.

    And yeah, look at the original post. The question was basically when would
    you use interfaces as opposed to abstract classes. No answer from anyone.

    How about this:
    Use interfaces when:

    1) Unrelated classes need to be supported
    2) There are already existing base classes
    3) Aggregation cannot be accomplished.

    that's it. In all other cases use abstract classes.

    Hook?line?sinker?



  2. #2
    David Bayley Guest

    Re: I'm amazed(The answer)

    Blob wrote:

    > And yeah, look at the original post. The question was basically when
    > would you use interfaces as opposed to abstract classes. No answer
    > from anyone.


    You had a question in your original post? Damned if I can see one
    amongst the insults. The quote you paraphrased was...

    "I know I cried out for inheritance, but I've found fewer uses of it
    than
    I expected. Interfaces, on the other hand, are my favourite tool."

    To which you replied...

    "What the **** does that mean? Interface inheritance not in your
    vocabulary?"

    Clearly you apply your blinkered C++ terminology whenever it is
    convenient. Stressing that interfaces are inherited in one moment, and
    then stressing that Single-Inheritance is a limitation in another. It
    betrays the shallow hyprocrisy of your trolling.

    > How about this:
    > Use interfaces when:
    >
    > 1) Unrelated classes need to be supported


    If they collaborate through an interface, then they *are* related.
    Interfaces merely _isolate_ the relation.

    > 2) There are already existing base classes


    Suggests a hack. Some sort of Adaptor is probably more appropriate.

    > 3) Aggregation cannot be accomplished.


    Aggregation can *always* be accomplished.

    > that's it. In all other cases use abstract classes.


    What are you talking about. I'm amazed. I laugh in your general
    direction. (The requisite Blob communique.)

    Superclasses (regardless of whether they happen to be abstract or not),
    shouldn't be introduced by default in languages like Java/C#/VB.NET. It
    doesn't matter how many exceptional rules you try to think up, it is an
    ***-about-face approach.

    The goal is to reduce coupling, so Interfaces should be used by default
    (whether explicitly in statically typed languages, or implicitly in
    dynamic ones).

    [Note: VB.NET is one of the rare hybrid languages that provides both
    static and dynamic modes. Smalltalk.NET is another.]

    Only when interfaces/aggregation is a pain in the ***, and the
    implementation relationship is so solid and time-saving, should
    implementation-inheritance (that's a non-pure abstract class for you C++
    folks) be used.

    > Hook?line?sinker?


    Just an expression. Here's another... Hoisted by your own petard.

    --
    David




  3. #3
    Blob Guest

    Re: I'm amazed(The answer)


    >You had a question in your original post? Damned if I can see one
    >amongst the insults. The quote you paraphrased was...
    >
    >"I know I cried out for inheritance, but I've found fewer uses of it
    >than
    >I expected. Interfaces, on the other hand, are my favourite tool."
    >
    >To which you replied...
    >
    >"What the **** does that mean? Interface inheritance not in your
    >vocabulary?"

    What the **** does that mean is a question. You should have followed a little
    closer.

    >
    >Clearly you apply your blinkered C++ terminology whenever it is
    >convenient. Stressing that interfaces are inherited in one moment, and
    >then stressing that Single-Inheritance is a limitation in another. It
    >betrays the shallow hyprocrisy of your trolling.

    Single(implementation) inheritance is a limitation. It has caused me to
    scream many times in the last 3 months. But they had to remove it because
    people like you cannot handle the dreaded diamond pattern(also from my blinkered
    C++ terminology). So, to conclude, interfaces are inherited and single(implementation)
    inheritance is a hinderance. Nuff said.


    >
    >> How about this:
    >> Use interfaces when:
    >>
    >> 1) Unrelated classes need to be supported

    >
    >If they collaborate through an interface, then they *are* related.
    >Interfaces merely _isolate_ the relation.

    What? Wow, arguing with the OO community on this one. I suggest reading
    JOOP. The reasoning comes directly from JOOP and now I am supposed to apply
    some dumbass VB programmers logic on OOP. Not likely.

    >
    >> 2) There are already existing base classes

    >
    >Suggests a hack. Some sort of Adaptor is probably more appropriate.

    Why an adaptor? A bridge has performed nicely for me in this instance.

    >
    >> 3) Aggregation cannot be accomplished.

    >
    >Aggregation can *always* be accomplished.

    Please elaborate? No it cannot always be done. A private nested class for
    example?


    >
    >> that's it. In all other cases use abstract classes.

    >
    >What are you talking about. I'm amazed. I laugh in your general
    >direction. (The requisite Blob communique.)

    Again, JOOP or David(whatever your last name is)? I think I will keep my
    $69 a year subscription since I don't see a DJOOP.
    >
    >Superclasses (regardless of whether they happen to be abstract or not),
    >shouldn't be introduced by default in languages like Java/C#/VB.NET. It
    >doesn't matter how many exceptional rules you try to think up, it is an
    >***-about-face approach.

    What? Oh, man again I am amazed. Jesus, how about Observer patterns tied
    to a composite pattern? Just did that the other day and it worked just fine
    in C#. How about CollectionBase in .NET? And I do believe if you look at
    the interfaces implemented, it does follow the three rules.

    >
    >The goal is to reduce coupling, so Interfaces should be used by default
    >(whether explicitly in statically typed languages, or implicitly in
    >dynamic ones).

    This reduces coupling? When you change the interface what happens to your
    clients? Add a method, recompile or add a whole new interface - version
    2. That's coupling at its best. How do you ship that new functionality
    on the IAmADumbass interface to your clients when you make a modification.
    You still have to issue the new one and let the old go on I do believe.
    Abstract classes on the other hand can be modified without affecting clients.
    No problem.
    >
    >[Note: VB.NET is one of the rare hybrid languages that provides both
    >static and dynamic modes. Smalltalk.NET is another.]

    I'll use my own little acronym here - WGAS(who gives a ****).
    >
    >Only when interfaces/aggregation is a pain in the ***, and the
    >implementation relationship is so solid and time-saving, should
    >implementation-inheritance (that's a non-pure abstract class for you C++
    >folks) be used.

    Please whip out your little handy dandy OO reference and look at the difference
    between composition and aggregation.



    >
    >Just an expression. Here's another... Hoisted by your own petard.

    Yeah, right. OK. Now explain. I had to look that up and it seems that most
    people who use this expression don't know what it means. Look it up.

  4. #4
    Kunle Odutola Guest

    Re: I'm amazed(The answer)

    Blob wrote:

    >>> How about this:
    >>> Use interfaces when:
    >>>
    >>> 1) Unrelated classes need to be supported

    >>
    >> If they collaborate through an interface, then they *are* related.
    >> Interfaces merely _isolate_ the relation.

    > What? Wow, arguing with the OO community on this one. I suggest
    > reading JOOP. The reasoning comes directly from JOOP and now I am
    > supposed to apply some dumbass VB programmers logic on OOP. Not
    > likely.


    Aha, the infamous "appeal to authority" fallacy.

    Kunle


  5. #5
    Jay Glynn Guest

    Re: I'm amazed(The answer)

    > What? Wow, arguing with the OO community on this one. I suggest reading
    > JOOP. The reasoning comes directly from JOOP and now I am supposed to

    apply
    > some dumbass VB programmers logic on OOP. Not likely.


    > Again, JOOP or David(whatever your last name is)? I think I will keep my
    > $69 a year subscription since I don't see a DJOOP.


    I wonder who your sending your $69.00 to since JOOP folded almost a year
    ago. At least that's when I got my letter saying thanks for the support but
    this is your last issue. Rolled it up into Appliction Development Trends I
    think.



  6. #6
    Blob Guest

    Re: I'm amazed(The answer)


    "Jay Glynn" <jlsglynn@hotmail.com> wrote:
    >> What? Wow, arguing with the OO community on this one. I suggest reading
    >> JOOP. The reasoning comes directly from JOOP and now I am supposed to

    >apply
    >> some dumbass VB programmers logic on OOP. Not likely.

    >
    >> Again, JOOP or David(whatever your last name is)? I think I will keep

    my
    >> $69 a year subscription since I don't see a DJOOP.

    >
    >I wonder who your sending your $69.00 to since JOOP folded almost a year
    >ago. At least that's when I got my letter saying thanks for the support

    but
    >this is your last issue. Rolled it up into Appliction Development Trends

    I
    >think.
    >
    >


    I believe it was more than a year ago but that's irrelevant. When I return
    home though I will send the exact article that held the information on interfaces
    vs. abstract classes. I believe it started in C++ report first and then
    carried over to JOOPMAG.

    Good thing I haven't had the wife send out that check. Thanks for reminding
    me Jay.


  7. #7
    Blob Guest

    Re: I'm amazed(The answer)


    "Kunle Odutola" <kunle.odutola@REMOVETHISokocha.freeserve.co.uk> wrote:
    >Blob wrote:
    >
    >>>> How about this:
    >>>> Use interfaces when:
    >>>>
    >>>> 1) Unrelated classes need to be supported
    >>>
    >>> If they collaborate through an interface, then they *are* related.
    >>> Interfaces merely _isolate_ the relation.

    >> What? Wow, arguing with the OO community on this one. I suggest
    >> reading JOOP. The reasoning comes directly from JOOP and now I am
    >> supposed to apply some dumbass VB programmers logic on OOP. Not
    >> likely.

    >
    >Aha, the infamous "appeal to authority" fallacy.
    >
    >Kunle
    >


    Nah, just the truth. I didn't get this smart on my own. I read a lot, ya
    know.


  8. #8
    Kunle Odutola Guest

    Re: I'm amazed(The answer)

    Blob wrote:

    > Nah, just the truth. I didn't get this smart-*** on my own.

    ^^^

    I'm sure you didn't.

    Kunle


  9. #9
    Blob Guest

    Re: I'm amazed(The answer)


    >> Nah, just the truth. I didn't get this smart-*** on my own.

    No, that part I did. Although my step father abused me as a child and that
    may have led to it also. He was a VB developer you know.

  10. #10
    David Bayley Guest

    Re: I'm amazed(The answer)

    Blob wrote:

    >> Clearly you apply your blinkered C++ terminology whenever it is
    >> convenient. Stressing that interfaces are inherited in one moment,
    >> and then stressing that Single-Inheritance is a limitation in
    >> another. It betrays the shallow hyprocrisy of your trolling.


    > Single(implementation) inheritance is a limitation. It has caused me
    > to scream many times in the last 3 months. But they had to remove it
    > because people like you cannot handle the dreaded diamond
    > pattern(also from my blinkered C++ terminology).


    Hello! Knock, knock on wood! I'm not arguing about the pros/cons of
    single-inherhitance. Stop trying to change the subject. You jumped on
    Rune's original post because he didn't prefix the term "Inheritance"
    with "Implementation".

    I just put a mirror in front of your face by jumping on the fact that
    you made exactly the same mistake. It's just semantics, and you need to
    be educated that different communities employ different semantics.

    >> If they collaborate through an interface, then they *are* related.
    >> Interfaces merely _isolate_ the relation.

    > What? Wow, arguing with the OO community on this one. I suggest
    > reading JOOP. The reasoning comes directly from JOOP and now I am
    > supposed to apply some dumbass VB programmers logic on OOP. Not
    > likely.


    I think you forgot to make a point there, just the usual VB bashing.

    >>> 2) There are already existing base classes

    >>
    >> Suggests a hack. Some sort of Adaptor is probably more appropriate.

    > Why an adaptor? A bridge has performed nicely for me in this
    > instance.


    If a Bridge has performed well for you, why did you make the point in
    the first place. Rather than stick to the point, you just attempt to
    change the subject to the subtle differences that exist between GoF's
    patterns.

    >>> 3) Aggregation cannot be accomplished.

    >>
    >> Aggregation can *always* be accomplished.

    > Please elaborate? No it cannot always be done. A private nested
    > class for example?


    Private nested classes? You've completely lost the plot. You were
    attempting to make some rules about when to use an Interface, so what do
    private nested classes have to do with anything?

    >> Superclasses (regardless of whether they happen to be abstract or
    >> not), shouldn't be introduced by default in languages like
    >> Java/C#/VB.NET. It doesn't matter how many exceptional rules you
    >> try to think up, it is an ***-about-face approach.

    > What? Oh, man again I am amazed. Jesus, how about Observer patterns
    > tied to a composite pattern? Just did that the other day and it
    > worked just fine in C#. How about CollectionBase in .NET? And I do
    > believe if you look at the interfaces implemented, it does follow the
    > three rules.


    I think .NET's CollectionBase sucks, I just implement ICollection. Are
    you so ignorant that you actually use it? Must be a problem with some
    C++ developers hooked on implementation inheritance.

    >> The goal is to reduce coupling, so Interfaces should be used by
    >> default (whether explicitly in statically typed languages, or
    >> implicitly in dynamic ones).

    > This reduces coupling? When you change the interface what happens to
    > your clients? Add a method, recompile or add a whole new interface -
    > version 2. That's coupling at its best. How do you ship that new
    > functionality on the IAmADumbass interface to your clients when you
    > make a modification. You still have to issue the new one and let the
    > old go on I do believe. Abstract classes on the other hand can be
    > modified without affecting clients. No problem.


    Sigh. Your first claimed rule for using Interfaces was that "Unrelated
    classes need to be supported". Here you seem to be not only agreeing
    with me that this is not true, you don't even think Interfaces *reduce*
    coupling.

    Of course, if you change the interface then clients need to be
    recompiled. The reduced coupling by introducing an interface is
    achieved by _isolating_ the coupling to that interface, independent from
    all the other members concrete classes might support.

    You really don't "get it" do you. Your just disagreeing for the sake of
    it.

    >> Only when interfaces/aggregation is a pain in the ***, and the
    >> implementation relationship is so solid and time-saving, should
    >> implementation-inheritance (that's a non-pure abstract class for you
    >> C++ folks) be used.

    > Please whip out your little handy dandy OO reference and look at the
    > difference between composition and aggregation.


    Another attempt to change the subject to a subtle difference. Its
    either clever trolling, or more likely ignorance. That's about the only
    concession I can hope to get from you, so thank you and good bye.


    --
    David




  11. #11
    Blob Guest

    Re: I'm amazed(The answer)


    "David Bayley" <dbayley@spamless.aebacus.com> wrote:
    >Blob wrote:
    >
    >>> Clearly you apply your blinkered C++ terminology whenever it is
    >>> convenient. Stressing that interfaces are inherited in one moment,
    >>> and then stressing that Single-Inheritance is a limitation in
    >>> another. It betrays the shallow hyprocrisy of your trolling.

    >
    >> Single(implementation) inheritance is a limitation. It has caused me
    >> to scream many times in the last 3 months. But they had to remove it
    >> because people like you cannot handle the dreaded diamond
    >> pattern(also from my blinkered C++ terminology).

    >
    >Hello! Knock, knock on wood! I'm not arguing about the pros/cons of
    >single-inherhitance. Stop trying to change the subject. You jumped on
    >Rune's original post because he didn't prefix the term "Inheritance"
    >with "Implementation".


    Let's go up 3 paragraphs here. You were following up on what I said about
    interfaces being inherited and a limitation all in one fail swoop. I was
    letting you know that single inheritance(OK, implementation) is a limitation.
    And I didn't jump on Rune's post about that. Are you telling me that you
    "DO NOT INHERIT INTERFACES"? If that is the case I would suggest to the
    compiler team at MS to change that because it sure does look like inheritance
    to me.



    >
    >I just put a mirror in front of your face by jumping on the fact that
    >you made exactly the same mistake. It's just semantics, and you need to
    >be educated that different communities employ different semantics.


    I don't believe so. Again, it is still inheritance. I was pointing out
    that he said he rarely used inheritance but came back about using interfaces
    regularly. Again, if that's not inheritance, I will back off. But when
    I see:

    class ShutYourPieHole : IKissMyAss

    Well, that looks like ShutYourPieHole is a IKissMyAss. Whether you like
    it or you can ShutYourPieHole and KissMyAss.


    >>> If they collaborate through an interface, then they *are* related.
    >>> Interfaces merely _isolate_ the relation.

    >> What? Wow, arguing with the OO community on this one. I suggest
    >> reading JOOP. The reasoning comes directly from JOOP and now I am
    >> supposed to apply some dumbass VB programmers logic on OOP. Not
    >> likely.


    >
    >I think you forgot to make a point there, just the usual VB bashing.
    >

    Point, you rebutted this statement. And this was not VB bashing. If you
    read clearly it says "some dumbass VB programmers logic on OOP". That was
    a reference to you not the entire VB community.

    >>>> 2) There are already existing base classes
    >>>
    >>> Suggests a hack. Some sort of Adaptor is probably more appropriate.

    >> Why an adaptor? A bridge has performed nicely for me in this
    >> instance.

    >
    >If a Bridge has performed well for you, why did you make the point in
    >the first place. Rather than stick to the point, you just attempt to
    >change the subject to the subtle differences that exist between GoF's
    >patterns.

    The POINT? Are you ****ing crazy? You brought up the Adaptor pattern.
    Me change the subject? I was asking you "Why an Adaptor". In the same cicumstances
    I have employed the Bridge. I was curious as to why you would choose an
    Adaptor. Again, you brought up patterns.


    >>> Aggregation can *always* be accomplished.

    >> Please elaborate? No it cannot always be done. A private nested
    >> class for example?

    >
    >Private nested classes? You've completely lost the plot. You were
    >attempting to make some rules about when to use an Interface, so what do
    >private nested classes have to do with anything?

    Again, you brought up that aggregation can always be done. How do you aggregate
    a private nested class? You brought this up not me. I guess I should spell
    that out for you.

    1) You said - "Aggregation can always be done"
    2) I asked you to elaborate
    3) I said in cannot always be done
    4) For example in the case of a private nested class how would you ****ing
    do AGGREGATION. I later asked you too look up aggreagation vs containment.
    Aggregation cannot always be done. Hence interfaces interfaces solve that
    problem nicely.

    >>> Superclasses (regardless of whether they happen to be abstract or
    >>> not), shouldn't be introduced by default in languages like
    >>> Java/C#/VB.NET. It doesn't matter how many exceptional rules you
    >>> try to think up, it is an ***-about-face approach.

    >> What? Oh, man again I am amazed. Jesus, how about Observer patterns
    >> tied to a composite pattern? Just did that the other day and it
    >> worked just fine in C#. How about CollectionBase in .NET? And I do
    >> believe if you look at the interfaces implemented, it does follow the
    >> three rules.

    >
    >I think .NET's CollectionBase sucks, I just implement ICollection. Are
    >you so ignorant that you actually use it? Must be a problem with some
    >C++ developers hooked on implementation inheritance.


    Again, you said superclasses should not be introduced by default into languages
    like Java/C#/VB.NET. I was referring to the design of the .NET library.
    Coincidentally, we have a library that has many types of containers, threading,
    data access, etc that are all derivatives of whatever classes or interfaces
    that apply. I don't use the .NET collections but our Utility Lib. Sorry
    about that. By the way, I do believe CollectionBase "****ING INHERITS" from
    ICollection doesn't it?




    >
    >>> The goal is to reduce coupling, so Interfaces should be used by
    >>> default (whether explicitly in statically typed languages, or
    >>> implicitly in dynamic ones).

    >> This reduces coupling? When you change the interface what happens to
    >> your clients? Add a method, recompile or add a whole new interface -
    >> version 2. That's coupling at its best. How do you ship that new
    >> functionality on the IAmADumbass interface to your clients when you
    >> make a modification. You still have to issue the new one and let the
    >> old go on I do believe. Abstract classes on the other hand can be
    >> modified without affecting clients. No problem.

    >
    >Sigh. Your first claimed rule for using Interfaces was that "Unrelated
    >classes need to be supported". Here you seem to be not only agreeing
    >with me that this is not true, you don't even think Interfaces *reduce*
    >coupling.

    NO, NO, NO. You said that interfaces should be used by default. Period.
    If you plan to ship your classes or interfaces which one do you choose?
    That is a question.

    What are you talking about with this crap? You talked about coupling here.
    End of story. I am assuming you do not understand the impact that interfaces
    place on coupling to your clients code? And don't ever say I agree with
    you. That will never happen.



    >
    >Of course, if you change the interface then clients need to be
    >recompiled. The reduced coupling by introducing an interface is
    >achieved by _isolating_ the coupling to that interface, independent from
    >all the other members concrete classes might support.
    >

    Of course. So is that coupling? If you modify an abstract class is the
    same true? Are you saying that your client is not coupled to the signature
    of that interface? You know what, what the **** are you saying.

    >>> Only when interfaces/aggregation is a pain in the ***, and the
    >>> implementation relationship is so solid and time-saving, should
    >>> implementation-inheritance (that's a non-pure abstract class for you
    >>> C++ folks) be used.

    >> Please whip out your little handy dandy OO reference and look at the
    >> difference between composition and aggregation.

    >
    >Another attempt to change the subject to a subtle difference. Its
    >either clever trolling, or more likely ignorance. That's about the only
    >concession I can hope to get from you, so thank you and good bye.


    That was the request for you too look at the difference between composition
    and aggregation.


    So long. I am off to kill some beer now and little birds tomorrow.

    BAAAAAAAAAAAAAM. Thud.

  12. #12
    Mark Jerde Guest

    Re: I'm amazed(The answer)

    Blob,

    > my step father abused me as a child and that
    > may have led to it also. He was a VB developer you know.


    LOL!

    -- Mark



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