Re: Ada OOP alternatives?

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Fri, 25 Jul 2008 10:47:49 +0200, Georg Bauhaus wrote:

[...] 
> Suppose you try to use an IDE in place of "separate",
> to hide away the details of Special_Case. Then the dependences
> on the with'ed package Ada.Text_IO and on All_Kinds_of_Things_Neccessary
> will have to be listed for the entire package.

Yes, but it would not change dependencies. The difference is merely visual,
wth-es appears in the parent body. So what? I never read with clauses. They
are semantically useless, impose a maintenance problem (GNAT does not
always warn about superfluous with's).

Better, there should be a "without" clause/pragma (:-))

> Observation 2:
[...]
> What amount of work is needed to make this reusable?

I cannot tell, because the example is ill-designed in my eyes. IMO, it
should be designed as a [private] child with:

   type Special_T is new T with ...; -- The "special case" is this
   overrides procedure Op (Item : T); -- This is an implementation of

So, yes, an ADT, even if it is a singleton today.

> Granted, there are cases when a child package seems a
> much better choice. For example, when the special communications
> procedure needs to maintain state information that is of
> no concern to any other subprogram anywhere.

Bad, very bad, design. Only objects should have states. Global variables is
a no-no. There cannot be stateful procedures otherwise than impure, with
global variables.

>>> Why, e.g., build an entire type when a single procedure
>>> is sufficient, and will be sufficient in the future?
>> 
>> How can you know that?
> 
> Sometimes the future of a program is known.  For example,
> known to end, because the strange device is no longer produced
> and the support has ended.  The special case procedure dies
> with the special case device/program.

Even if a strange device is no more produced, it is still used by
customers. And customer requirements change. Bad design never pays off.

>>> Many languages have a function type
>>> built in, functions are objects.
>> 
>> But not in the sense of a stateful object of OO.
> 
> Yes, there are function objects in the sense of a stateful object
> of OO.

Hmm, if you mean active objects, like Ada task types, then observe that
they are not procedures. A task type has methods (entry points), which are
procedures.

If you mean a procedural abstraction of some external stateful thing, like
random generator, then it is a bad design. The state should be explicitly
bound to some visible object to which the procedure would be applied.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de