From: Jeff Brooks on
topmind wrote:
> Unfortunately, I don't want to release it public because I want some
> security through obscurity. I might release snippets though. There are
> plenty of existing wiki's implementations anyhow, and my approach does
> not significantly differ than them (although I feel I factored better
> than some of those I looked at).

So you are not going to support your claims with any evidence as usual.

If your past posts is any indication of your future behavior you will
continue to complain that the OO people never provide any evidence and
forget that your are guilty of the same thing.

Jeff Brooks
From: Jeff Brooks on
topmind wrote:
>
> Jeff Brooks wrote:
>
>>topmind wrote:
>>
>>
>>>And right off the bat in this link:
>>>
>>>http://www.ratio.co.uk/white.html
>>>
>>>They define a hierarchy of bank account types. I have ranted against
>>>this before. To satisfy how customers really want stuff, you just
>>>cannot use hierarchies. Customers want a smorgishbord, not hierarchies.
>>>See:
>>>
>>>http://www.geocities.com/tablizer/mellor.htm#customerplans
>>
>>Classification hiearchies don't need to be used to model everything in
>>OO. Your argument in this case is very weak.
>
> I didn't say they were. I was addressing a specific example of
> polymorphism.

"They define a hierarchy of bank account types. I have ranted against
this before. To satisfy how customers really want stuff, you just cannot
use hierarchies. Customers want a smorgishbord, not hierarchies."
- topmind

The link you supplied is also about issues with hierarchical
classification.

Jeff Brooks
From: Jeff Brooks on
topmind wrote:
> Again, you describe "edits" in terms of a hierarchical taxonomy or list
> of mutually-exclusive choices ("sub-types"). How many times do I have
> to say that trees and mut-ex. is poor modeling?

How many times do we have to tell you that you don't need to model
everything in OO with huge classification trees?

Jeff Brooks
From: Peter Seibel on
Christer Ericson <christer_ericson(a)NOTplayTHISstationBIT.sony.com> writes:

> In article <m264wkq336.fsf(a)gigamonkeys.com>, peter(a)gigamonkeys.com
> says...
>> [...] I don't really disagree with any of the authorities you cite
>> [...] However all these quotes seem to be describing what an
>> object is. Which is fine as far as it goes. But a different--to my
>> mind--question, is what features make a language OO? It's the
>> latter question that I'm interested in (and that I thought we were
>> talking about, but I jumped in mid-conversation so it's quite
>> possible I'm wrong).
>
> I wasn't trying to comment on the definition of 'object-oriented.'
> I was merely pointing out that the bit of your text that I posted
> back at you, which paraphrased read as "OO is the organization of a
> program in terms of ADTs" is incorrect (in that it categorizes
> e.g. SML programs as OO).

Ah, well then we don't really disagree at all. You quoted, IIRC, this
sentence:

The fundamental idea of object orientation is that a powerful way to
organize a program is to define data types and then associate
operations with those data types.

However by "associate operation with those data types" I meant a bit
more than just "define operations on those data types" though I see
how you could read what I wrote as meaning the latter. However if you
look at the very next sentence, I say:

In particular, you want to be able to invoke an operation and have
the exact behavior determined by the type of the object or objects
on which the operation was invoked.

I.e. I'm talking about runtime-dispatched polymorphic operations. And,
indeed, I wind up the paragraph saying:

This feature of object orientation [i.e. the one I started out the
paragraph talking about] goes by the fancy Greek name polymorphism,
meaning "many forms," because a single conceptual operation, such as
drawing an object, can take many different concrete forms.

> It seems you yourself do not support your own sentence because you
> in this last post say "my claim is that support for runtime-
> dispatched polymorphic operations is both a necessary and sufficient
> characteristic of OO languages."

Well, that's what I was trying to get at in that paragraph from which
you quoted the first sentence. I perhaps colud have made it more clear
that that's what I was trying to say; then, at least, we could be
having a discussion on what I think is the more interesting
question--is there any other necessary or sufficient feature of an OO
language than runtime-dispatched polymorphic operations?

> I apologize for avoiding commenting on the "what then is object-
> orientedness" bit of your post. I don't have time to give a
> fully thought out response.

Pity.

-Peter

--
Peter Seibel * peter(a)gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp * http://www.gigamonkeys.com/book/
From: Jeff Brooks on
topmind wrote:
>
> Jeff Brooks wrote:
>
>>There have already been a few examples posted. Read them.
>
> Nobody has provided a definite URL so far.

Yes they have. Look at past messages.

>>That's an illogical argument.
>>
>>Do you think if a customer doesn't give a damn about the structure of a
>>procedural program that means the structure won't affect the future
>>maintainability of the software?
>
> I am not sure what you mean. I am only saying that real world changes,
> such as customer preferences, don't usually change in a hierarchical
> way over time. If you want change-friendly software, your software
> should not hard-wire itself to tree-based changes.

Then don't hard-wire the trees into the code!

>>That's an illogical argument.
>>
>>The problem would only exist if you had to model everything as a single
>>rooted classification tree. That isn't true so your argument is meaningless.
>
> Are you suggesting multiple inheritance?

There are ways of modeling non-hierarchical cclassifications in every OO
language I have seen.

For example:

In java there is interfaces which support multiple inheritance. An
interface can be applied to any node in a tree and do not have to apply
to any parent of the node. This allows non-hierarchical classification
in Java.

In dynamic languages (Smalltalk, ruby, python, Objective-C etc) the
structure of a tree has no impact on the ability to assign it. As long
as the object can respond to the same messages that another object can
it can be used no matter what it's parent is.

In C++ there multiple inheritance so multiple parents are supported.

In Self dynamic/multiple inheritance is supported so it's not a problem.

In JavaScript it uses a prototype base system so different parts can be
assembled together to support behavior from multiple "classes".

etc etc

>>How did you measure that polymorphism is worse?
>
> It is objectively more code rework if you want to change it to a HAS-A
> model when trees fail. If you start out with a HAS-A model, obviously
> it is easier to accept more has-a's without lots of code rework.

Deep classification trees is considered bad OO. It's good practice to
have a forest rather than a single tree for classification.

Having lots of small hierarchies that have HAS-A relationships is the
normal way things are modeled in OO.

Bad design is always difficult to change which is true in procedural
code as well.

Jeff Brooks
First  |  Prev  |  Next  |  Last
Pages: 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38
Next: Use Case Point Estimation