Re: Can't export object of private type

[nospam@thanks.com.au (Don Harrison)]

Sam Mize wrote:

:Don Harrison <nospam@thanks.com.au> wrote:
:> Matt Heaney wrote:
:
:> :If you know up front how many "instances" of an abstraction you have
:> :--what I call the "well-known objects" pattern-- then a state machine
:> :package is probably the way to go.  
:> 
:> Partitioning objects into "well-known" and less-well-known :)  will always 
:> be somewhat arbitrary.
:
:Perhaps a clearer term would be "enumerable" if this kind of confusion is
:going to occur.  It doesn't seem arbitrary to me that either you can list
:all the objects up front, by their nature, like the planets -- or not.

I think you're right that this kind of abstraction usually is enumerable
but the property which suggests their implementation as a state machine is 
that their underlying behaviour is well-defined and isn't expected to change. 
This quality obviates the need for an explicit derivable type.

The problem, of course, is that you're relying on foresight in anticipating 
no future requirement for variants. We can forsee future needs to some extent 
but not perfectly. 


:>However, in the context of non-pure OOPLs (such as 
:> Ada), you're probably right in suggesting it's worth distinguishing between 
:> single-fixed-variant (your "well-known") objects and more general ones. 
:> The additional flexibility gained in declaring an explicit derivable type 
:> is a waste of time if future variants are unlikely.
:
:Is it not a waste of time in an OOPL, or is it not possible to avoid
:doing it in an OOPL?  (That sounds confrontational and I apologize, but
:I can't think of a better way to phrase it.)

A decent pure OOPL (such as Eiffel) will leave open the possibility of 
deriving variants. Eiffel doesn't give you a choice - every class can 
have heirs, although you can freeze particular primitive operations if 
you choose. The downside is a loss of execution speed - roughly 15% of 
dispatching calls aren't optimised to non-dispatching calls (Gnu Eiffel).


:> :In a typical Ada application, some abstractions are implemented as state
:> :machine packages, and some abstractions are implemented as instances of
:> :an abstract data type.  There is nothing odd or unnatural about this.
:> 
:> It's certainly idiomatic.
:
:Does you mean this to counter Matt's statement?  

No. I mean to agree that it's idiomatic - even if I disagree with the 
philosophy leading to the idiom. :)

Ada allows you to choose the degree of reusability for abstractions. Many 
Ada developers exercise that choice and choose lower reusability and that 
may be reasonable for abstractions that have little prospect of changing. 
I prefer to err on the side of more reusability .. which inevitably makes 
my code less idiomatic.

:If a language forces you
:to use just one or the other, you would, and that would be idiomatic too.

Certainly - for example, idiomatic Eiffel maximises derivability.

:I'm not sure what you're trying to get across.

Agreement with the expressed facts without disagreeing with the underlying 
philosophy that leads to them. :)


-- 
Don (Harrison).   donh at syd.csa.com.au