From: Rob Thorpe on 13 Jun 2005 14:15 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 13 Jun 2005 15:16 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 13 Jun 2005 22:14 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 13 Jun 2005 22:45 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 14 Jun 2005 00:44
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 | +----------------------------------------------------------------+ |