comp.lang.ada
 help / color / mirror / Atom feed
From: Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>
Subject: Re: Ada OOP alternatives?
Date: Fri, 25 Jul 2008 10:47:49 +0200
Date: 2008-07-25T10:47:50+02:00	[thread overview]
Message-ID: <48899335$0$18824$9b4e6d93@newsspool2.arcor-online.net> (raw)
In-Reply-To: <cdgybr77wil1.jruauobv9o9z.dlg@40tude.net>

Dmitry A. Kazakov wrote:
> On Thu, 24 Jul 2008 12:20:07 +0200, Georg Bauhaus wrote:
> 
>> Dmitry A. Kazakov wrote:
> 
>>>>> then in 80s, but it is no any problem now. IDEs do it better.
>>>> Ada IDEs cannot affect semantics?
>>> I am not sure what you mean... GPS does affect the semantics when you
>>> change some project options.
>> I meant the semantics of child packages and separate units
>> as given in the program text.
> 
> I lost your point. Can you elaborate it a bit more?


package News23 is

   type T is null record;
   procedure Op(Item: T);

end News23;

package body News23 is

   procedure Special_Case(Item : T);
   --  Makes XYZ(Item) known to neighbouring Funnix process Foo

   procedure Op(Item: T) is
   begin
      if True then   -- imagine real life conditional here
         Special_Case(Item);
      end if;
   end Op;

   procedure Special_Case(Item : T) is separate;

end News23;


with Ada.Text_IO;   -- or some Sockets, or ....
with All_Kinds_of_Things_Neccessary; -- for the special case

separate(News23)
procedure Special_Case(Item : T) is
begin
   null;
end Special_Case;

Observation 1:

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.
So IDEs cannot help with dependences. You need separate units
or child packages.

Observation 2:

The single Special_Case procedure will serve its purpose
by informing the other (Funnix) side as needed.

Now instead of just the procedure Special_Case, which does
what is needed, I could construct an ADT Special_Process.
This type should, IIUC, reflect a general Special-Case-Communications
idea so
1/ it matches the other side and
2/ is an ADT (reusable?).

package The_Far_Away_Company is

   subtype Code is Natural range 200 .. 599;

   type Message is new C.char_array;
   function To_Special_Message(ID: Code; Message: String);

   type Special_Process is private;
   procedure Send(The_Process: Special_Process;
      The_Message: Message);

end The_Far_Away_Company;

What amount of work is needed to make this reusable?

I'll just pack it into the local part of a very private
single-purpose procedure separated from the others in the body.

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.


>> 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.


>> 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. They even have execution in steps, and can refer to relatively
global objects that might be updated during (virtually) stepwise
execution of the function.




  reply	other threads:[~2008-07-25  8:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-15 20:38 Ada OOP alternatives? raould
2008-07-16  0:15 ` Robert A Duff
2008-07-16  6:33   ` Georg Bauhaus
2008-07-16  9:54     ` Alex R. Mosteo
2008-07-16 13:03       ` Dmitry A. Kazakov
2008-07-16 14:07       ` Robert A Duff
2008-07-16 18:11         ` (see below)
2008-07-17  0:05           ` Robert A Duff
2008-07-17  0:43             ` (see below)
2008-07-17  1:36               ` Robert A Duff
2008-07-17 11:07                 ` (see below)
2008-07-17 16:45                   ` Robert A Duff
2008-07-17 12:00                 ` Dmitry A. Kazakov
2008-07-17 16:50                   ` Robert A Duff
2008-07-17 18:56                     ` Dmitry A. Kazakov
2008-07-18 12:54                       ` Robert A Duff
2008-07-18 13:36                         ` Dmitry A. Kazakov
2008-07-17 23:27                 ` Randy Brukardt
2008-07-18 12:45                   ` Robert A Duff
2008-07-18 23:22                     ` Randy Brukardt
2008-07-22 20:32                 ` Adam Beneschan
2008-07-22 22:18                   ` Ludovic Brenta
2008-07-23  9:25                     ` Alex R. Mosteo
2008-07-22 23:35                   ` Randy Brukardt
2008-07-23  7:56                   ` Dmitry A. Kazakov
2008-07-23 21:04                     ` Robert A Duff
2008-07-24  7:07                       ` stefan-lucks
     [not found]                       ` <5ob7w7usrc74$.kms2e1vqs4k0.dlg@40tude.net>
     [not found]                         ` <48883529$0$18826$9b4e6d93@newsspool2.arcor-online.net>
     [not found]                           ` <ygdmhl22lzh4$.1dx98hja6p2o6.dlg@40tude.net>
     [not found]                             ` <48883f41$0$18829$9b4e6d93@newsspool2.arcor-online.net>
     [not found]                               ` <6i1s0y8eeka.121ek9qcgunha$.dlg@40tude.net>
     [not found]                                 ` <48885757$0$18818$9b4e6d93@newsspool2.arcor-online.net>
2008-07-24 12:48                                   ` Dmitry A. Kazakov
2008-07-25  8:47                                     ` Georg Bauhaus [this message]
2008-07-25 13:28                                       ` Dmitry A. Kazakov
2008-07-25 16:24                                         ` Georg Bauhaus
2008-07-25 17:55                                           ` Dmitry A. Kazakov
2008-07-26  5:05                   ` Jeff Koftinoff
2008-07-16 14:03     ` Robert A Duff
2008-07-16 14:29       ` Dmitry A. Kazakov
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox