Speaking of strings...

[Jason]

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

[Tom Shelton]

"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

[Ed Courtenay]

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

[Jason]

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.

[Jason]

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.

[Phil Weber]

> 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

[Larry Serflaten]

"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

[W.E. (Bill) Goodrich, PhD]

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

[Mike Mitchell]

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

[Mike Mitchell]

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

[Mike Mitchell]

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

[Tom Shelton]

"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

[Larry Serflaten]

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

[Mike Mitchell]

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

[Patrick Steele [MVP]]

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