Speaking of strings... - Page 7


DevX Home    Today's Headlines   Articles Archive   Tip Bank   Forums   

Page 7 of 17 FirstFirst ... 56789 ... LastLast
Results 91 to 105 of 247

Thread: Speaking of strings...

  1. #91
    Jason Guest

    Re: Speaking of strings...


    "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:
    >In article <3da5cb02$1@10.1.10.29>,
    >"Jason" <jason@hotmail.com> writes:
    >
    >> "W.E. (Bill) Goodrich, PhD" <bgoodric@netzero.net> wrote:

    >
    >> > ***snip***

    >
    >Interesting to note how much relevant material was excised with
    >that snip - including the "inconvenient" specifics that you seem
    >unable to address. Predictable, but interesting from a psychological
    >POV.


    Look, I am trying to tell you to keep it short. I don't have time to respond
    to 100 points in a 50 page document. I also do not believe that the length
    of an argument necessarily makes it more right or wrong.


    >
    >Wrong again.
    >
    >> You simply don't know how to think "OO" in a practical way.

    >
    >Apparently, the problem here is your unwillingness (inability?) to
    >critically examine the claims of the OO propaganda.
    >
    >> Classes provide encapsulation. #1 trait of OO.

    >
    >That claim is no longer accepted as valid, outside of the
    >oversimplifications of the classroom. In fact, that claim has been
    >debunked both in the Software Engineering and Academic communities.
    >Since you have complained about your difficulties with reading
    >comprehension, I will only cite one of the many examples from each:
    >
    >Software Engineering:
    > http://www.cuj.com/articles/2000/000...topic=articles


    So this article says that sometimes writing a non-member function is good.
    In real world programming, this seems obvious. The fact that someone would
    have to write an article to explain this fact makes me think that this is
    targeted toward theoreticians. There seems to be nothing in this article
    that an experienced programmer would not know from experience.

    I am not arguing that OO should be used to the exclusion of all other techniques.
    I am arguing that OO, when used in addition to other techniques, helps make
    complex problem sets more managable.


    >Academia:
    >http://researchweb.watson.ibm.com/hy...rs/sac2000.pdf


    This article is all written for Java, and all the terminology is targeted
    at OO. And academia. Lots of big words to describe a medium-sized idea.
    I'll wait for the movie, thanks.


    >While the original theory was that classes would provide
    >encapsulation, the modern reality is that they do not necessarily
    >do so - and they often interfere with both encapsulation and
    >modularization.


    The key phrase being "not necessarily." This depends somewhat on the implementation,
    with scoping constructs being very important, especially at the package level,
    or namespace level. I agree that C# and Java could do more in this area.
    It would be good to have inter-package scoping at times, but neither language
    allows this. Object level and in-package scoping are sometimes not enough.

    Still, what is there is better than name-mangling and unenforcable encapsulation.


    >> That makes things more modular.

    >
    >Not necessarily. Modularity and encapsulation are not the same thing.


    No, but see if you can follow me here. Good encapsulation hides complex
    code behind simpler interfaces. Data and code are combined together, meaning
    all you have to deal with is the interface. Not the code. Not the data.
    This is modular.

    If it does not apply in every case, fine. It applies in most cases, which
    makes it a good tool. Good tools do not need to be perfect.


    >> "friend" classes are defined differently in different languages.
    >> The more modern thought on this is to wrap things into namespaces
    >> or packages, with classes that are in the same namespace having some
    >> extra access. This is something that is necessary to encapsulation
    >> in practice.

    >
    >And ironically, something that is inimical to encapsulation in practice.


    >And even more inimical to modularity.


    If used incorrectly. There is no language or programming practice that I
    have heard of that completely prevents bad programmers from writing bad code,
    or prevents people who don't understand correct and incorrect uses of the
    toolsets they have available from writing bad code.


    >> Inheritance is a very useful tool - when combined with well thought,
    >> stable code libraries.

    >
    >And a quick road to disaster when misused. But the currently relevant
    >part of that is that it offers a major route for careless violation of
    >both encapsulation and modularity.


    If you don't know how to use the toolset, then you will probably write bad
    code. What don't you understand about this? If you have been taught good
    OO practices, and you have practical experience with it, then you tend to
    correctly. Are you incapable on common sense on this point?


    >> A good example is the java.io library. You can extend an
    >> OutputStream and use it polymorphically in lots of other places.

    >
    >How special. You can also corrupt it - a good indication of the
    >broken modularity.


    Okay, what would you suggest would be better? Let's have a specific example.
    You are really good at pointing out the flaws in everything. Show me a
    methodology for programming where the programmer can't screw anything up.
    Please explain it in such a way that even someone of my limited intellect
    can understand.

    Or shut up.

    >> Yes, there are other ways to do polymorphism,

    >
    >And here again, you have slid entirely into one of the predicted games,


    >as described in the excised part of the previous post:
    >
    >: A few of the more thoughtful ones will throw in some circular
    >: arguments on the order of "it makes it easier to do OO" and/or
    >: "it makes it quicker and easier to program the way I like to - OO".
    >: None have been able to show objective benefits over a completely
    >: equivalent MP construct for any specific problem domain.


    Okay, let me throw this back at you. You show me how your beloved MP programming
    thingy is superior to your basic OO programming.

    Again, please make it simple so I can understand it.


    >
    >Since "polymorphism" is explicitly an OO construct, your argument
    >reduces to "this OO construct is good because it addresses this other
    >OO construct". That CLAIMED benefit completely avoids the issue under
    >discussion (the extent to which the constructs break modularity), and
    >is not linked to anything outside of your little circle.
    >
    >But the interesting issue here is whether you are even capable of
    >making your arguments without such circular appeals to OO specific
    >constructs? Can you (personally) even define polymorphism in a
    >concrete way, without doing so in terms of other OO constructs? I
    >seriously doubt it.


    Well, I could break down an object into a virtual function table associated
    with some arbitrary data set, and say that if you have multiple virtual function
    tables that have compatible functions, then you can swap a pointer to those
    function tables, thereby creating polymorphism. Of course, you would have
    to use pointers, which would ruin enforcable encapsulation. So nyah. :-P



    >> but it is a lot cleaner when you don't have to implement every
    >> method on the object from scratch. Sometimes.

    >
    >Of course, that argument tries to take "as given" the claim that the
    >OO construct "polymorphism" is a desirable (even necessary) end to
    >itself, rather than one of many means to a more valid end. But that
    >is not a given.


    Nope, it is not useful or advisable in every situation. That does not mean,
    however, that it is not a useful construct, and even the best solution (given
    our current technology) in some cases.


    >And the argument is another clear example of the "unequal examples"
    >argument style I cited. There is nothing about non-OO modularity that
    >would justify the description "have to implement every method on the
    >object from scratch" (leaving aside the OO specific "method" and
    >"object").


    Again I ask you, give me an example of something better.


    >> When done correctly, OO code is very modular, stable, and easy
    >> to maintain over time.

    >
    >The classic circular argument, since the speaker can turn around and
    >say that "by definition" any OO code which has the stated problems
    >"was not done correctly". Predictable (and predicted).
    >
    >But the issue is not what would happen under your unrealistically
    >ideal circumstances. It is what can - and does - happen under common
    >real world conditions. No matter how you try to squirm and hide
    >behind your weasel words, you reinforce the fact that you simply don't
    >know how to think "OO" in a practical way.


    And no matter how you phrase your arguments, you cannot hide the fact that
    you are a pompous ***. If you knew how to think OO in a practical way, you
    would understand that it is a toolset. You don't have to use it all the
    time, but it is there when you need it. And it can be very useful. And
    if it is done correctly, the code that results is clean, robust, and maintainable.

    I have actual real world experience using a number of different programming
    tools. The ones that that have a strong OO base seem to me to be the most
    productive.

    Granted, I do not use C++, but then I never saw that as being a good OO alternative
    for several reasons, which I won't go into here.


    >> >As to making it easier to organize, the
    >> >only people making that argument with a straight face are those who
    >> >were taught such a limited range of organizational strategies and
    >> >skills that they are unable to conceptualize the problem domain in
    >> >any other way.

    >
    >> I guess, then, that I am among those poor unfortunate souls who
    >> just aren't as smart as you are, Bill.

    >
    >Your problem seems more one of ignorance and lack of insight than of
    >intellect. The biggest problem seems to be your tendency to stop
    >thinking when you reach one of the major OO buzzwords.


    Yep. Pompous ***. Just because I don't agree with your point of view does
    not mean I am not thinking.

    Again, I am not an OO purist. I am a very good programmer who uses the stuff
    on a day to day basis. I find, from experience, that it is far easier to
    organize things using OO tools than without them. That does not mean that
    there cannot be something better out there, or that the OO tools cannot be
    improved.

    But I can tell you this. I write good code, and I use OO for a lot of it.


    Very simple. Take my OO tools away, I am less productive. That does not
    mean I solve every problem using exclusively OO stuff. I don't. In fact,
    I am a strong opponent of "too much inheritance." But a little inheritance
    can be a very good thing.


    >
    >> But then again, both Sun and Microsoft seem to have picked up this
    >> "OO" thing and are running with it,

    >
    >In response to market forces. Just as Sony primarily manufacturers and
    >sells (and promotes) the technically inferior VHS tapes (instead of
    >their own - technically superior - Beta format) in the US marketplace.
    >In this case, a major element in the M$ decision is the OO nature of
    >Java, which M$ is trying to fight for specific user bases. The more
    >interesting element is the extent to which the INTERNAL code of both
    >companies follows non-OO patterns.


    Want to give some examples of non-OO patterns? This is too vague and argument
    for me to rebut or accept.

    And maybe the reason Beta failed is that it could not tape for 6 hours at
    a time. Beta gave clearer pictures at 2 hours, but no pictures at 6. As
    everyone knows, 6 hours of blurry porn is better than 2 hours of crystal
    clear porn.


    >> and I can see definite advantages to using the new stuff over,
    >> say, VB3.

    >
    >And another predictable response - the gratuitous comparison to a
    >much earlier version of a specific language IDE. If you really
    >believed in your argument, you would have compared something like
    >a fully and carefully modular VB6 subprogram with a fully equivalent
    >OO VB6 subprogram.


    Okay, I will. I worked at IBM for about 10 months. I was on a VB5 project
    during that time. The development team had used modular programming to develop
    the whole app. There was a rather complex part of the application called
    the "Rollup-Engine" that was falling apart. Global variables shared among
    multiple modules and a dependance on arrays were killing it.

    Anyway, my tech lead and me sat down one day, came up with a design using
    custom collections and polymorphism, and broke out the tasks so that each
    programmer could write one of the polymorphic objects.

    The original schedule for the new features was 3 months. We did a complete
    rewrite using OO techniques (as much as could be done in VB at the time)
    in about 4 weeks, with no programmer spending more than about 3 weeks on
    their part.

    Could this have been done with modular programming and a lot of discipline?
    Yep. But the fact that I was able to define an interface and make the programmers
    conform to that interface helped the process along. The fact that we were
    able to use collections of data rather than arrays (especially considering
    some of the limitations of VB arrays at the time) was priceless.

    Do you know of a better way to do arbitrary hierarchical collections of data
    in VB than with OO? There is a way if you avoid encapsulation, but I don't
    much like that solution.

    I was at IBM for 10 months. I got a bronze award during that time, and was
    hired out by another company for about twice what I was making because of
    what I did for that project.


    >> So maybe, just maybe, you are full of crap.

    >
    >Another of the predictable - and predicted - responses.


    Well, it is easy for you to predict that response when it has happened so
    many other times.

    >
    >> See if you can keep the response to under 10,000 words.

    >
    >Not too difficult, given the lack of substance in your post.
    >
    >> And put down the **** thesaurus and speak common English so I don't
    >> have to pull out the dictionary every time I read one of your posts.

    >
    >While I sympathize with your claimed limitations in terms of literacy,
    >the only words or phrases I use here that I don't use in everyday
    >conversation are things like the URLs. My children - one in middle
    >school, one in High School - have read many of my posts, and neither
    >had any problem with the vocabulary.


    And in this post, you kept it simple. Thanks.


  2. #92
    Tom Shelton Guest

    Re: Speaking of strings...


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:46vdqucnvdu931934ihp0bh8jsq61nn3r8@4ax.com...
    > On Fri, 11 Oct 2002 09:20:24 -0500, "Larry Serflaten"
    > <serflaten@usinternet.com> wrote:
    >
    > >Thus, instead of thinking in terms of PanWash, and PotWash, and so
    > >on, I can abstract that to any dish, using a Dish interface that supports
    > >Wash, Rinse, and Dry. I can then loop through the Dishes array and
    > >apply its own Wash, Rinse, and Dry methods, without having to know
    > >how they are actually accomplished. As I said, that allows me to code
    > >in more abstract terms to get the job done, than had I been forced
    > >to use many separate arrays, and many different methods.

    >
    > So how is this different from using Wash, Rinse, and Dry functions,
    > then passing the type of dish in question? In my Wash function, for
    > example, I would have a Select Case to permit structured delineation
    > between the kinds of washing available. If later a new kind of dish
    > needed washing, I could add to the function as appropriate, just as
    > you would have to add a new Wash method to your OOP approach.
    >
    > So, what *is* the advantage of Pot.Wash over Wash(Pot)?



    One advantage I see is maintenance... I don't end up with a gargantuan Wash
    function that I have to update every time I want to wash a new dish - I
    simply let it implement the IWashable interface, and pass it to the Generic
    Wash function. And if there's a bug in the washing of pots, I just go to
    the Pot class and fix it there - I don't have to wade through a bunch of
    extraneous pan, cup, or plate washing code.

    Tom Shelton



  3. #93
    Ed Courtenay Guest

    Re: Speaking of strings...


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:46vdqucnvdu931934ihp0bh8jsq61nn3r8@4ax.com...
    > On Fri, 11 Oct 2002 09:20:24 -0500, "Larry Serflaten"
    > <serflaten@usinternet.com> wrote:
    >
    > >Thus, instead of thinking in terms of PanWash, and PotWash, and so
    > >on, I can abstract that to any dish, using a Dish interface that supports
    > >Wash, Rinse, and Dry. I can then loop through the Dishes array and
    > >apply its own Wash, Rinse, and Dry methods, without having to know
    > >how they are actually accomplished. As I said, that allows me to code
    > >in more abstract terms to get the job done, than had I been forced
    > >to use many separate arrays, and many different methods.

    >
    > So how is this different from using Wash, Rinse, and Dry functions,
    > then passing the type of dish in question? In my Wash function, for
    > example, I would have a Select Case to permit structured delineation
    > between the kinds of washing available. If later a new kind of dish
    > needed washing, I could add to the function as appropriate, just as
    > you would have to add a new Wash method to your OOP approach.
    >
    > So, what *is* the advantage of Pot.Wash over Wash(Pot)?
    >


    One of the main advantages is not having to modify your Select Case
    structure, since you hand the specifics over to the object itself.

    Imagine you have an array of items that need washing, and that those items
    implement an interface called IWashable;

    Dim item As IWashable
    For Each item In itemList
    item.Wash
    Next

    Simple. You do not need to know the specific type of each item in the
    array - it's irrelevant. At a later date when you implement a new item, lets
    say VerySharpKnife which also implements IWashable, you do not need to
    modify the code above.




  4. #94
    Jason Guest

    Re: Speaking of strings...


    Good examples, Larry.

    I also like the "collections" example. How do you do arbitrary collections
    which can contain arbitrary collections? That is a very powerful construct
    which lends itself to OO quite well. If you are using only modular programming,
    you have to pass in something like arrays with pointers in them. And you
    better get the function calls right.

    With VB, you can use variant arrays inside of variant arrays, forming a tree
    structure.

    This breaks encapsulation, since anyone can get at any of the data, and incorrect
    code can operate on data it was not meant to see.

    Also, if you look at it, a variant array is really a special type of object.
    So is a String. So if you take away the variant array and stick to plain
    arrays and structures (Types in VB), you really need to use byte arrays and
    pointers to represent strings, and pointers to arrays to represent structure.
    That is, if you want to approach this from a purist point of view.


    Bill, show me a good way to do arbitrary collections using only MP. I know
    there are ways, but all the ones I can think of do not enforce encapsulation
    and require significantly more code to implement. Let's go with VB-classic,
    since you brought that up in an earlier post, and I reserve the right to
    use my library of collections, which are encapsulated but do not use inheritance.

    Show me the MP construct, and how it is superior to the OO construct, and
    I will issue a public apology and sing the praises of MP right here on this
    very forum.

    Put up or shut up.

  5. #95
    Jason Guest

    Re: Speaking of strings...


    Mike Mitchell <kylix_is@yahoo.co.uk> wrote:

    >So how is this different from using Wash, Rinse, and Dry functions,
    >then passing the type of dish in question? In my Wash function, for
    >example, I would have a Select Case to permit structured delineation
    >between the kinds of washing available. If later a new kind of dish
    >needed washing, I could add to the function as appropriate, just as
    >you would have to add a new Wash method to your OOP approach.
    >
    >So, what *is* the advantage of Pot.Wash over Wash(Pot)?
    >
    >MM


    The difference is encapsulation. In your version, you would:

    (1) Have complete access to all the data in "Pot" from anywhere in the program,
    and

    (2) be forced to modify your original Wash() function everytime you added
    a new dish.

    I'm assuming that you are using a Type or an Array to store your Pot data
    here, by the way.

    With an Interface and polymorphism, you would need to implement Wash() once
    for every new type of dish you create, but all the data for Pot would be
    hidden inside the object. That way, you know no one who is using Pot can
    alter it or see inside it (unless you provided them a method to do that).

    With inheritance, you can create a base dish object, and that object can
    have a base Wash() function, and store the base data for all dishes. Now,
    if you wash a Pot the same way as other dishes, there is nothing else to
    do. If you wash a Pot like a dish, but you also have to wash the handle,
    then you can call the base method and then add code just to wash the handle.

    Note: Inheritance can be tricky, is often misused, and can make code more
    difficult if not carefully thought out beforehand. This is a simplified
    example, but in the real world, things are usually trickier.

    ***********
    But in my opinion, the most important thing in this example is encapsulation.
    When you add a new type of dish, if you use the OO way instead of the Wash(Pot)
    way, you are assured of not breaking everyone else's code if you make a mistake.



    One other thing:

    If your code is fairly simple anyway, there really is no practical difference.
    OO constructs help when the coding gets complicated. When there are lots
    of programmers, or lots of different modules where the possibilities of interaction
    start to grow unmanagable.

    OO lets you define a set of interfaces, so you can hide the complex data
    and functions. This limits the number of interactions that other code can
    have with your objects, and makes it easier to keep the whole thing in your
    head at one time.

    And OO is NEVER "necessary." It can always be done a different way. For
    large software projects, though, OO has proven itself, to me at least, to
    be a very good toolset for dealing with complexity in software.


  6. #96
    Phil Weber Guest

    Re: Speaking of strings...

    > I don't have time to respond to 100 points in a 50
    > page document.


    Jason: So why do you keep doing it? ;-) PhD will never acknowledge that you may
    have a valid point; he will continue to argue incessantly and condescendingly
    until you get tired and give up. Please save yourself (and the rest of us) a
    great deal of time and let him have the last word now. Thank you!
    --
    Phil Weber



  7. #97
    Larry Serflaten Guest

    Re: Speaking of strings...

    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote
    >
    > So how is this different from using Wash, Rinse, and Dry functions,
    > then passing the type of dish in question?


    How about considering what you are going to ask, before asking it?
    If you don't see a difference, then use the OO methods.

    > In my Wash function, for
    > example, I would have a Select Case


    That's an argument for modularity, not OO principles.
    If you like conglomorating code, why have a separate function?
    Why not make one big procedure, with several calls to Gosub?
    And then. ultimately, why use Gosub?

    LFS




  8. #98
    W.E. (Bill) Goodrich, PhD Guest

    Re: Speaking of strings...

    In article <3da6d792@10.1.10.29>,
    "Larry Serflaten" <serflaten@usinternet.com> writes:

    > "Mr. (Bill) wrote


    If you are going to use that construct, it would be "Dr. (Bill)"

    > > But the interesting issue here is whether you are even capable of
    > > making your arguments without such circular appeals to OO specific
    > > constructs? Can you (personally) even define polymorphism in a
    > > concrete way, without doing so in terms of other OO constructs? I
    > > seriously doubt it.


    > Polymorphism is the means by which abstracted tasks can be entered
    > into code, in place of many similar functions and methods.


    So a simple cut and paste edit of the relevant source code would
    constitute polymorphism. Interesting.

    What? You say there is "something more" to the definition - something
    "understood"? Then you haven't really defined it at all, have you? All
    you have done is throw some words up - words carefully chosen to
    obfuscate the issue - and gone on to argue based on that fallacy.

    > Do you see OO constructs in that definition?


    I see the glaring gap in that definition. A gap which divides your
    claimed definition from the way you, Jason, Tom, Ed, et al use the
    term. And until you explicitly fill that gap, questions about what I
    do - or do not - "see" in that definition are nothing but empty
    rhetoric.

    > Just to flesh out an example,


    With, as usual, a poorly defined, unrealistic "example" presented in
    an even more unrealistic manner.

    > consider:


    > You have to wash the Dishes, you have Pots and Pans, and Cups and
    > Saucers that all need washing, rinsing, and drying.


    Is this an automated process, a "sims" type computer game, or just the
    usual nonsense about a semidefined manual process being thrown out in
    an attempt to play definition games?

    > To gather the input, you'll need a array for the Pots, another for
    > the Pans, a third for Cups, and another for the Saucers.


    Why? Already, you are making poorly considered and defined design
    decisions. And it is interesting that you are choosing that subset of
    items for your problem definition, then using others later in your
    argument. How and when are you differentiating between those items to
    be washed? Why do you need to collect them rather than handling them
    individually? Such questions can - should - have a profound effect on
    the design process.

    > They are all washed and dried differently, pots are washed with a
    > pot washing method and dried with a pot drying method, the pans are
    > washed with a pan washing method and dried with a pan drying method,


    Why the difference between the two? And what is the difference between
    the two?

    > and so on.


    > Finally, all the dishes need to be washed and rinsed, then they can
    > all be dried.


    Again, why? Why not dry as we go along?

    > Now, where you will have to have separate subs for each of the
    > types and each of the methods, (PotWash, PanWash, PotDry, PanDry...)


    Why? That would seem to be a very poor design decision even GIVEN the
    earlier parameters.

    > you are going to have to call them in order looping through each array
    > type to wash and rinse, and loop again through all the types to dry.


    Again, why? That would seem to be a very poor approach.

    > Using OO and Polymorphism, I still write the separate subs for each
    > of the types, but I can simplify the code by using one array for the
    > dishes, where each type of dish supports its own Wash, Rinse, and Dry
    > methods.


    Thereby spreading common functionality all over creation rather than
    concentrating it in one place - violating one of the primary tenets of
    modular programming. And potentially creating nightmares for anyone
    trying to maintain and/or extend the code.

    > Thus, instead of thinking in terms of PanWash, and PotWash, and so
    > on, I can abstract that to any dish, using a Dish interface that
    > supports Wash, Rinse, and Dry.


    And can do exactly the same thing with neither OO nor polymorphism,
    doing so in a way which concentrates related functionality in one
    place rather than spreading it out across the map.

    > I can then loop through the Dishes array and apply its own Wash,
    > Rinse, and Dry methods, without having to know how they are actually
    > accomplished.


    Just as you could with the modular equivalent (even given your other
    questionable "rule" decisions). The difference comes when you are
    coding the specifics of "how they are actually accomplished."

    > As I said, that allows me to code in more abstract terms to get the
    > job done, than had I been forced to use many separate arrays, and
    > many different methods.


    Nothing about using the non-OO approach would "force" such an idiotic
    program structure.

    > The advantage there is evident.


    As is the strained nature of your example. As usual, your example is
    extremely unrealistic, and your description of the "alternative" has
    been carefully crafted to be artificially crude and inappropriate.

    > You can use your old methods if you want, I'll opt for the OO
    > techniques, as will many others.


    And then they will no doubt beat a hasty retreat before the long term
    maintenance issues can come back to haunt them. Charming.

    --

    W.E. (Bill) Goodrich, PhD

    *-----------------------*--------------------------------------------*
    * CHANGE YOUR SEXUALITY * http://www.nyx.net/~bgoodric/ctg.html *
    * * *
    * Without Aversive * ctgcentral@earthlink.net *
    * Behavior Modification * Creative Technology Group *
    * or Drugs * PO Box 286 *
    * * Englewood, CO 80151-0286 *
    *-----------------------*--------------------------------------------*

  9. #99
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Fri, 11 Oct 2002 10:56:20 -0600, "Tom Shelton" <toms@dakcs.com>
    wrote:

    >One advantage I see is maintenance... I don't end up with a gargantuan Wash
    >function that I have to update every time I want to wash a new dish - I
    >simply let it implement the IWashable interface, and pass it to the Generic
    >Wash function. And if there's a bug in the washing of pots, I just go to
    >the Pot class and fix it there - I don't have to wade through a bunch of
    >extraneous pan, cup, or plate washing code.


    Doesn't sound very convincing. More like: You say tomayto, I say
    tomahto. The code for the new washing function/method is going to have
    to be added SOMEwhere.

    MM

  10. #100
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Fri, 11 Oct 2002 17:58:51 +0100, "Ed Courtenay"
    <my-first-name@edcourtenay.co.uk> wrote:

    >Simple. You do not need to know the specific type of each item in the
    >array - it's irrelevant. At a later date when you implement a new item, lets
    >say VerySharpKnife which also implements IWashable, you do not need to
    >modify the code above.


    But if your VerySharpKnife also implements IWashable, I can equally
    say *my* VerySharpKnife also implements an existing function without
    code modification. What happens, though, if your VerySharpKnife needs
    a *new* washing process altogether?

    MM

  11. #101
    Mike Mitchell Guest

    Re: Speaking of strings...

    On 11 Oct 2002 10:25:13 -0700, "Jason" <jason@hotmail.com> wrote:

    >With inheritance, you can create a base dish object, and that object can
    >have a base Wash() function, and store the base data for all dishes. Now,
    >if you wash a Pot the same way as other dishes, there is nothing else to
    >do. If you wash a Pot like a dish, but you also have to wash the handle,
    >then you can call the base method and then add code just to wash the handle.


    So you add the handle washing code to the Pot method. What happens if
    Jugs now appear and also need their handles washed? You're going to
    have to add the handle washing code to the Jug method, too.

    MM

  12. #102
    Tom Shelton Guest

    Re: Speaking of strings...


    "Mike Mitchell" <kylix_is@yahoo.co.uk> wrote in message
    news:6fnequch806p54tqjpo5pp00dm775fen8s@4ax.com...
    > On Fri, 11 Oct 2002 10:56:20 -0600, "Tom Shelton" <toms@dakcs.com>
    > wrote:
    >
    > >One advantage I see is maintenance... I don't end up with a gargantuan

    Wash
    > >function that I have to update every time I want to wash a new dish - I
    > >simply let it implement the IWashable interface, and pass it to the

    Generic
    > >Wash function. And if there's a bug in the washing of pots, I just go to
    > >the Pot class and fix it there - I don't have to wade through a bunch of
    > >extraneous pan, cup, or plate washing code.

    >
    > Doesn't sound very convincing. More like: You say tomayto, I say
    > tomahto. The code for the new washing function/method is going to have
    > to be added SOMEwhere.


    Yes, isolated in the object that it applies to - where it belongs. The
    generic function never has to be touched again once written, it will
    automatically be able to handle any Washable object.

    Tom Shelton



  13. #103
    Larry Serflaten Guest

    Re: Speaking of strings...

    Mr. (Bill) wrote
    >
    > If you are going to use that construct, it would be "Dr. (Bill)"


    I'll reserve that title to those who do not destroy any shread of
    respect one might have for such a title.

    >
    > > Polymorphism is the means by which abstracted tasks can be entered
    > > into code, in place of many similar functions and methods.

    >
    > So a simple cut and paste edit of the relevant source code would
    > constitute polymorphism. Interesting.


    I guess its easy to make up your own translation when you don't want to
    understand what was said.

    LFS



  14. #104
    Mike Mitchell Guest

    Re: Speaking of strings...

    On Fri, 11 Oct 2002 19:46:31 -0600, "Tom Shelton" <tom@mtogden.com>
    wrote:

    >Yes, isolated in the object that it applies to - where it belongs. The
    >generic function never has to be touched again once written, it will
    >automatically be able to handle any Washable object.


    But that approach would effectively leave little boxes of "detergent"
    all over the place - in objects here, there and everywhere, whereas my
    approach to concentrating all the functionality in one place means
    that I only have one place to look when I need to debug or enhance.
    After all, it's the *code* that gets debugged or enhanced, not the
    data. An analogy of the differences between OOP methods and
    traditional functions seems to go like this: When I do the laundry, I
    gather up all the clothes from where I've left them (I'm an untidy
    slob) and carry them to the kitchen where my washing machine is. But
    your approach would favour lots of mini washing machines in various
    places - the bathroom, the bedroom, the kitchen, the lounge (THE
    LOUNGE, MIKEY?!!!). Each room would have its own laundry method,
    whereas I prefer to move the "data" to one central location. Also,
    then, I can arrange to have a really super-powerful washing machine in
    the one place, and I don't have to run pipes all over the house to
    supply water.

    You say: "isolated". But what if when another object requires the
    same, or very similar, code? Does it, too, receive a special touch,
    also in splendid isolation from all the other objects? Is it not just
    a lot simpler, when a new kind of dish comes along, to just call the
    one function, having modified the latter to provide the new
    functionality?

    MM

  15. #105
    Patrick Steele [MVP] Guest

    Re: Speaking of strings...

    In article <ojnequ44v43272vvjdjfteplg3mn2mkngj@4ax.com> (from Mike
    Mitchell <kylix_is@yahoo.co.uk>),
    > What happens, though, if your VerySharpKnife needs
    > a *new* washing process altogether?


    I won't touch this one Mike. Let's just say your (lack of) knowledge in
    OOP was eloquently expressed here.

    --
    Patrick Steele
    Microsoft .NET MVP
    http://radio.weblogs.com/0110109

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