From: Rob Thorpe on
Phlip wrote:
> Rob Thorpe wrote:
>
> > * Alternatively, let's say there are several functions like "operation"
> > that operate on pObject. In fact, the programmer never need manipulate
> > pObject directly or know what's inside it. In this case it would be OO
> > code. It's written in a language that isn't object orientated, but
> > it's OO all the same.
>
> That's encapsulation.

Well I would say a little bit more than that. I would assume that any
number of "struct object" could be created.

>
> > I don't think that a program that otherwise combines associated code
> > and data should be classified as not being OO simply because it doesn't
> > use polymorphism.
>
> The problem with your definition is it lets in Visual Basic Classic. Yuck!

Well, it lets in many programs that are written in VB Classic yes. It
also lets in C programs that use OO like the windows interfaces we
mentioned earlier. I'm sure if I had my head with me today I could
come up with a way of writing OO programs in DOS batch.

Part of the usefulness of this definition is that it includes many
programs that would not be included by defining OO in terms of
polymorphism. For example, a program written in C++ that happens not
to use virtual methods is still be considered an object-orientated
program. It would confusing to consider the program becoming OO all of
a sudden once if it needed to use a virtual method somewhere.

It allows yuckiness in, but so do all definitions.

From: Rob Thorpe on
Peter Seibel wrote:
> "Rob Thorpe" <robert.thorpe(a)antenova.com> writes:
>
> > Peter Seibel wrote:
> >> "Rob Thorpe" <robert.thorpe(a)antenova.com> writes:
> >>
> >> > The textbooks I refer to certainly aren't lame since they use the
> >> > normally accepted defintion of OO - ie. that written in most books and
> >> > used by most programmers. I have never read a book that ties OO to
> >> > polymorphism as you have tried to, but I would be interested to know if
> >> > such a misleading text exists.
> >>
> >> Hmmm. What is this "normally accepted definition of OO" of which you
> >> speak? Anyway, for such a misleading text, try:
> >>
> >> <http://www.gigamonkeys.com/book/>
> >>
> >> in particular Chapter 16:
> >>
> >> <http://www.gigamonkeys.com/book/object-reorientation-generic-functions.html>
> >
> > Nice book, I had no idea it was available online, that's very useful.
> >
> > Christer Ericson has already made most of the important points, at
> > least as well as I could have done.
> >
> > The difference between our viewpoints occurs when a program makes
> > use of structures that encapsulate data and code together hiding the
> > data's representation do not go as far as using polymorphism. I
> > think you would call the structures in such a program ADTs whereas I
> > would call them objects. (This is really only a small change in
> > nomenclature).
>
> So I'm still curious what you (and others who take the "polymorphism
> is only an incidental feature of OO" position) say about programs
> written in languages generally not considered "OO" that use the (good)
> engineering technique of creating ADTs. Is a C program written in
> terms of structs and functions that operate on those structs OO? Does
> that make C an OO language?
>
> > I use this definition for three reasons:
>
> Just to be clear, definition of what? An object? Or object
> orientation. I draw this distinction because they aren't necessarily
> the same. Suppose for the sake of argument that I'm right and that
> having support for runtime-dispatched polymorphic operations is the
> single necessary and sufficient feature to make a language OO.

It's not really a question of right and wrong, it's a question of
definition and usage of a term.

> It
> might still be the case that all OO languages happen to use an
> ADT-like structuring of code and data according to the definitions
> Christer cited. Support for creating such ADTs may even be a necessary
> (but not sufficient) feature of OO languages.

Yes, I would agree that that would be a necessary feature of an OO
language. I would consider that a sufficient feature for an OO
language. But I was talking about programs not languages ...

> On the other hand, if you're saying that support for creating
> "combining" data and operations on that data (what you call an object
> and I call and ADT)

ADT's are not normally closed, that is you cannot normally perform
every operation needed on them using only the operation provided.
Occasionally you must go directly to the data.

> is the only necessary and sufficient
> characteristic of an OO language, then I'm still curious what
> languages you're thinking of that you consider OO that have this
> characteristic but *not* runtime-dispatched polymorphic methods. If
> you want to say C--at least when used the right way--is an OO
> language, that's cool. But then I'll say any language can be OO if
> used in the right way.

I wasn't talking about languages originally. Way up this huge thread
Philip said "The point of OO is encapsulating polymorphism behind
encapsulated interfaces". This defines OO in terms of polymorphism,
which is confusing firstly since it's not the common usage, secondly
because it excludes object-orientated programs that don't use
polymorphism. I see polymorphism as a tool to the encapsulation aim,
not a defining characteristic. See my reply to Philip elsewhere in
this thread.

I certainly don't think that C is an object-orientated language just
because you can write OO programs in it. It doesn't have any features
to support OO programming by making it easier. It can be used to do it
because it's a flexible procedural language.

> But then I'd be curious to know if there's a
> term for that set of languages that support runtime-dispatched
> polymorphic operations.

Never come across one, though one would be useful.

From: Jeff Brooks on
topmind wrote:
>>You make claims all the time and have no proof.
>
> Like what? Even if I did, does that give you license to also be an
> idiot?

You can't remember what you posted and your calling me an idiot?!

Jeff Brooks
From: Jeff Brooks on
topmind wrote:
> Jeff Brooks wrote:
>
>>We've been through this before.
>>
>>OO is the standard right now.
>
> That is hogwash. Most developers do not use OO, just OO languages. And,
> even if it was, being popular is not the same as being good. Otherwise
> Microsoft is the Nervana of perfection.

I didn't say that popularity implies quality.

>>If the OO guys don't prove their point OO will remain the standard. If
>>you don't prove your point OO will remain the standard.
>>
>>If you prove your point then things may change. You may not like it but
>>if you don't prove your point then you lose the argument by default.

.... snip ...

>>That might be a valid point if all OO models require deep
>>classifications trees but OO doesn't so you point is meaningless.
>
> If they don't, then the alternatives are also simple. And how do
> you know up front whether classifications will remain simple forever?

You can't.

You can make designs in procedural code that will break as new
requirements come up. That isn't an OO issue its a basic maintenance
issue that affects all languages.

> OO is supposed to make software easier to change, but you appear to
> refute that claim.

I'm not refuting the claim. Please read what I wrote.

>>Like the way you try to find a few cases where classification trees
>>aren't the perfect model and ignore that in the majority of cases it
>>works fine?!
>
> Again, if we are only talking about trivial hierarchies, then most
> approaches will be adequate. If nothing changes and it all stays
> simple, then it ain't matter either way. OO fans often brag about how
> OO allegedly scales in "big applications". You seem to be contradicting
> that.

I'm not contradicting it. Again, please read what I wrote.

> Classification philosphers have discovered this
> centuries ago. Like I said earlier, even many existing OO gurus agree
> that trees are limited to rely on often. They are just not as vocal as
> I am about it.

I understand that a single rooted tree isn't perfect for classification.
If you bothered to read my posts you would know that I agree with you
that it's not perfect.

However, the amount of problems that require a non-hierarchical
classification are rare and OO languages have ways of dealing with the
rare cases.

It appears your making the illogical argument "if it's not perfect for
everything then it's bad at everything".

I could use the same illogical argument against procedural and say that
procedural is bad because it's poor for device drivers.

I'm sure you would disagree with the previous statement. I hope you can
understand why I disagree with your argument.

Jeff Brooks
From: Charles Richmond on
CBFalconer wrote:
>
> Charles Richmond wrote:
> >
> ... snip ...
> >
> > You can get some chess rules in Acrobat (.pdf) format at:
> >
> > <http://www.ihsa.org/activity/ch/ 2004-05/chess%20rule%20book%2004-05.pdf>
>
> Broken URL, and I can't figure out where. Terminating at "ch/"
> doesn't bring up any elucidation. Nor does eliminating the blank.
>
I was able to upload the .pdf by removing the blank...
try use the following URL:

<http://www.ihsa.org/activity/ch/2004-05/chess%20rule%20book%2004-05.pdf>

--
+----------------------------------------------------------------+
| Charles and Francis Richmond It is moral cowardice to leave |
| undone what one perceives right |
| richmond at plano dot net to do. -- Confucius |
+----------------------------------------------------------------+
First  |  Prev  |  Next  |  Last
Pages: 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
Next: Use Case Point Estimation