Re: limited types (Was: Records that could be arrays)

On Sun, 26 Feb 2006 22:07:00 GMT, Matthew Heaney wrote:

"Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> 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 classes 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
.

Relevant Pages

  • Re: pointers to elements in containers
    ... The 'key_fields' container is meant to store pointers to the ... so Detail's constructor looks like the ... pointers to elements in 'fields' point to valid ... Is your Detail struct being copied? ...
    (microsoft.public.vc.language)
  • Re: default values - the good, the bad and the ugly
    ... > The thing is that in your tale, they didn't change only a constructor ... In the specific case the someClass is a container of ... geometric curves, 'd' is the c0 continuous tolerance between ... the capacity reserved would be double the last size. ...
    (comp.lang.cpp)
  • Re: Equivalent to VCLs DataModule
    ... components if it implements System.ComponentModel.Component's constructor which takes a System.ComponentModel.IContainer as a parameter? ... a constructor taking IContainer and calling IContainer.Add, so that if you for example drag drop your component onto a form, VS ensures that your component will be added to the form's Container object. ... Does the IDE know to look for a private variable of type System.ComponentModel.Container in a CLR object in order to have that object act as a container for other objects at design time? ...
    (microsoft.public.dotnet.framework)
  • pointers to elements in containers
    ... The 'key_fields' container is meant to store pointers to the std:string's in ... locations only until the end of the constructor after which they change (if ... Addresses of the elements in a vector may change after resize(), ...
    (microsoft.public.vc.language)
  • Re: [std::vector] operator[], the heap and try-carch blocks
    ... However, if the container contains ... You should be able to get away without their use by setting data members to ... complicated resource acquisition in the constructor body. ... thereby allowing you to complete object construction ...
    (alt.comp.lang.learn.c-cpp)