From: Randy Brukardt on
"Maciej Sobczak" <see.my.homepage(a)gmail.com> wrote in message
news:fef531f2-0f35-4ba5-8e79-9ae59e2a6a25(a)x21g2000yqa.googlegroups.com...
> On 10 Cze, 08:13, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote:
....
>> (Probably copying a crappy design from some other
>> language.) There should be almost no visible access types
>
> Well, not so fast. Access types are necessary for referring to
> existing objects.
> Think about request handlers in AWS, for example - the idea is that
> objects are *registered* somewhere for future use. How would you do
> that without access types? At least obtaining the 'Access value is
> necessary, even if the explicit use of access variables can be
> avoided.

I'm talking about in the interfaces. Ada always allows you to take 'Access
of tagged parameters, so the implementation of a class can surely do that if
needed. But it should never, ever, expose that cruft to the clients.

This is exactly how Claw works: a mess of access type cruft under the
covers, almost no access types in the interfaces. The only existing access
types are used to return access to existing objects; that will remain in the
Ada 2012 design but it will be safe (unlike in the Ada 95 Claw design)
because the lifetime of the returned access will have to be shorter than the
existing objects (absent Unchecked_Deallocation, the destroyer of all that
is safe ;-), and you won't actually have to write any of the dereferencing
(it will look syntactically like you are reading/modifying the object itself
in place).

Randy.


From: Stephen Leake on
Vadim Godunko <vgodunko(a)gmail.com> writes:

> On Jun 10, 10:13 am, "Randy Brukardt" <ra...(a)rrsoftware.com> wrote:
>>
>> Maybe in C++, but in Ada, if you are defining OOP using pointers, you are
>> doing something wrong. (Probably copying a crappy design from some other
>> language.) There should be almost no visible access types (and I say almost
>> only to allow the accessor magic of Ada 2012).
>>
> I want to known more about how to use OOP in Ada without access types!

I have an example of using Ada.Containers instead of access types at
http://www.stephe-leake.org/ada/access_vs_object.html

Ada 2005 isn't really ready for this; Ada 2012 will come closer, but I
think Randy is overstating his case.

--
-- Stephe
From: Stephen Leake on
"Randy Brukardt" <randy(a)rrsoftware.com> writes:

> Claw only uses a handful of access types in its interfaces (internally is a
> different story, but irrelevant to this discussion).

No, it's not irrelevant, if we are talking about implementing libraries,
rather than using them!

--
-- Stephe
From: Stephen Leake on
Georg Bauhaus <rm.dash-bauhaus(a)futureapps.de> writes:

> On 10.06.10 10:57, Vadim Godunko wrote:
>> On Jun 10, 11:20 am, AdaMagica <christoph.gr...(a)eurocopter.com> wrote:
>>> On 10 Jun., 08:34, Vadim Godunko <vgodu...(a)gmail.com> wrote:
>>>
>>>> I want to known more about how to use OOP in Ada without access types!
>>>
>>> type Element is tagged ...
>>> subtype Any_Element is Element'Class;
>>>
>>> procedure Show (E: Element);
>>>
>> Thank you for example, this is example of dispatching but not use of
>> Ada in heavy OOP style of programming. :-)
>
> Will it, in theory, be possible to write a Qt-like library
> in Ada such that client programs declare variables like
>
> W : Some_Window'Class := Some_Lib_Pack.Make (Typ => Some_Id);
>
> That is, programs do not use access Some_Window'Class?

No. Because the underlying C++ uses pointers, so the Ada has to as well.

--
-- Stephe
From: Alex R. Mosteo on
J-P. Rosen wrote:

> Alex R. Mosteo a écrit :
>> Martin Krischik wrote:
>>
>> (...)
>>
>>> function f returns Integer
>>>
>>> package i is
>>> g : Integer := 0;
>>> end i;
>>>
>>> begin
>>> i.g := i.g + 1;
>>> return i.g;
>>> end f;
>>
>> Do you mean that i.g retains value across calls here? Never saw this
>> construct before, and not what I would have thought... interesting.
> No! In Ada, no construct lives longer than its scope (unlike C static
> variables)

Yep, I saw in other reply. I admit it was a most unsettling idea at first
sight.