On Sun, 26 Feb 2006 22:07:00 GMT, Matthew Heaney wrote:
> "Dmitry A. Kazakov" <mailbox@[EMAIL PROTECTED]
> writes:
>
>> On Sun, 26 Feb 2006 18:20:39 GMT, Matthew Heaney wrote:
>>> Huh? An Ada 2005 constructor function *is* a constructor. It's no
>>> different from a copy ctor in C++.
>>
>> No. The constructor is wrapped by the function. Differently to a true
>> constructor, you cannot ensure the wrapper will always be called for
some
>> specified signature.
>
> This is a specious argument. If you says the "real" constructor is
wrapped by
> a function then you're guilty of moving the goal-posts.
>
> We're talking about requiring that a constructor be called. The syntax
doesn't
> matter. That fact that Ada 2005 spells it f-u-n-c-t-i-o-n is
irrelevent.
There is a fundamental difference between a subprogram and a constructor.
A
subprogram can implement a part of a constructor (like Initialize), it can
call to a constructor (like Copy), but it cannot *be* a constructor.
Constructors are not decomposable into subprograms. Copy is a subprogram
as
any other. That means, other subprograms can do exactly the same, i.e. you
have a backdoor wide open.
> If you want to force a constructor to be used, then you can make the
partial
> view of the type indefinite.
It is not a programmer's choice and not a question of view. There should
be
absolutely no way to pass construction by.
>> 3. Containers of specific types building a parallel types hierarchy.
I.e.
>> if S is a subtype of T, then a container type with the elements of S is
a
>> subtype of a container type with the elements of T.
>
> You have totally misunderstood the design of the Ada 2005 container
library.
>
> When you use cursors, then this abstracts-away the container itself,
leaving
> you with a sequence of elements. This model works for all the
containers
> already (and for arrays too, in fact).
>
> Write your algorithms in terms of sequences of elements instead of
containers,
> and you can forget about containers.
No, thanks. If I wished that sort of untyped design, there would be C++
and
dynamically typed languages at my disposal. I don't want untyped
containers. I would keep boxes for apples and barrels for herrings in
separate rooms.
>> If the compiler knew that Copy is a constructor it could safely compose
it
>> out of constructors of the bases and the components (in most of cases.)
>
> In practice concrete derived cl***** must implement their own ctors,
that call
> the ctor of the base class.
It must be called automatically, like in C++. It is already so in Ada for
the parts generated by the compiler. You cannot override construction of
the components. There is no reason to treat user-defined parts otherwise.
You can skip Initialize, when you inherit and cannot when you aggregating.
Nonsense.
> In the case at hand, you need an operation that takes type ET'Class,
which is
> the type used to instantiate the generic, so you have to write it
yourself, the
> same as for any other operation.
This is an untyped model. As I said, I prefer a contract-based model. If
copyable type is the contract, that should require a copy constructor.
>> And this is an argument? (:-))
>
> This ignores the history of Ada language evolution:
>
> Ada83: no function pointers; royal pain
> Ada95: function pointers at library-level only: GUI callbacks, etc
> Ada05: function pointers in nested scopes too
>
> No one seems to agree with you, Dmitry! The trend has been to allow the
> declaration of "ugly" function pointers in more places, not fewer.
When Ada 95 added function pointers, it just admitted that functions are
regular objects. When Ada 05 allows anonymous access types for functions
it
only pursues this idea of regularity further. I see no reason how this can
contradict to functions as values? Why a function cannot be passed as a
normal "in" parameter of limited type? Give me a reason. Why don't we
write: "not null access Integer" to pass Integer?
Further, considering distributed systems, how to marshal a function to
remote node, if functions does not have values?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
|
