Re: Real OO

[donh@syd.csa.com.au (Don Harrison)]

Matt Kennel writes:

:Don Harrison (donh@syd.csa.com.au) wrote:
:: What I'm basically saying about Eiffel is that it's use would tend to maximise 
:: reusability and flexibility in developed software due to the defaults of the
:: language:
:
:: a) reusability - the default is that a routine is extendable (not frozen)
:: b) flexibilty  - the default is that entities are polymorphic, so will maximise 
::                  (theoretical) dynamic binding when used as actual parameters.
::                  This equates to flexibility, IMO.
:
:: I acknowledge you can do exactly the same things in Ada but believe an Ada 
:: programmer would typically use static binding more often than an Eiffel 
:: programmer and would tend to use classwide operations more than an Eiffel 
:: programmer.
:
:I'm an Eiffel fan but I'd disagree here.  "polymorphism" is not like alms
:for the poor.  Per se more 'polymorphism' doesn't mean 'better', it just 
:means 'more polymorphism'.

My naive reasoning is that if an entity is polymorphic, it can be used in more
places than a non-polymorphic one because it represents a family of types rather
than a specific type. Isn't that entity more flexible to use?

What do others think?

:Personally I have lots of success with the Sather approach, where you can
:use concrete classes when you need to be specific about the type and
:abstract classes when you don't. 

Jon seems to suggest that Sather's concrete and abstract classes are similar 
to Ada's specific and classwide types. How are they different? Is there any
similarity with Eiffel deferred classes?

:These concrete classes are always available as sources for future
:implementation.
:
:You can get the same effect in Eiffel if the compiler has a common
:optimization.

... of static binding for routines which are not redefined in descendants?

:  Never inherit from those classes which you want to use as a
:"final" concrete non-dispatching version.  If you want to use their
:implementation in the future, then get it from a differently named 
:superclass.

So, it's freezing on class rather than routine basis?

:If the compiler notices that a class has no descendants (and this fact can
:be discerned at at compile time) then it should not have to dispatch
:calls.  
:
:So, if you see a class FOOBAR and you want to use it like it's concrete:
:make a new class MY_SPECIAL_CONCRETE_FOOBAR and inherit FOOBAR and
:don't do anything else.  Very simple. 
:
:The only difference in Sather is that you needn't make a separate
:concrete class from which you get implementation: a concrete class
:is both 'final' (not dispatchable) and remains a source of implementation
:for others.

So, you may inherit from it (but not redefine it's features)?
Would this be equivalent to freezing all the features in a class? If that is so,
Eiffel offers a finer granularity of control. Typically, in Eiffel, you would
define frozen and normal routines within the same class rather than define a
separate class.

Can you give some examples?
 
:: Don.
:
:matt

Don.