* Prologue and epilogue aspects
@ 2018-01-26 19:56 Dmitry A. Kazakov
2018-01-27 7:17 ` Randy Brukardt
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-01-26 19:56 UTC (permalink / raw)
While we are at [limited] controlled interfaces why not to make them safer?
I would propose a simple aspect Composition for primitive procedures
(including interfaces). The aspect has values: Prologue | Override
(default) | Epilogue | Final
procedure First (...) with Composition => Prologue;
when overridden the parent type's body is called before the override.
procedure Last (...) with Composition => Epilogue;
when overridden the parent's body is called after successful completion
of the override.
procedure Always (...) with Composition => Final;
when overridden the parent's body is always called after completion of
the override. The exceptions from the override are re-raised after
successful execution of the body.
The aspect is inherited if overriding does not change it.
[Variant: the aspect cannot be changed if the override does not have a
full view of the type.]
The aspect inherited from interfaces is overridden by the aspect
inherited from a full type [diamond inheritance].
Conflicting aspects from multiple interfaces must be explicitly overridden.
----------------------------------------------------------------
Now Ada.Finalization will declare Controlled as follows:
type <anonymous> is interface;
procedure Initialize (Object : in out <anonymous>) is
abstract with Composition => Prologue;
procedure Adjust (Object : in out <anonymous>) is
abstract with Composition => Prologue;
procedure Finalize (Object : in out <anonymous>)
abstract with Composition => Epilogue;
--
-- Old code will continue "enjoying" manual calls to parent
-- Initialize, Adjust, Finalize
--
type Controlled is abstract new <anonymous> with private;
overriding
procedure Initialize (Object : in out Controlled) is
null with Composition => Override;
overriding
procedure Adjust (Object : in out Controlled) is
null with Composition => Override;
overriding
procedure Finalize (Object : in out Controlled) is
null with Composition => Override;
--
-- New code with have things as they should have been
--
type Controlled_Interface is new <anonymous>;
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-26 19:56 Prologue and epilogue aspects Dmitry A. Kazakov
@ 2018-01-27 7:17 ` Randy Brukardt
2018-01-27 9:33 ` Dmitry A. Kazakov
0 siblings, 1 reply; 15+ messages in thread
From: Randy Brukardt @ 2018-01-27 7:17 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4g15r$1s60$1@gioia.aioe.org...
...
> type Controlled is abstract new <anonymous> with private;
This unfortunately doesn't fix anything. An interface never can be hidden
(only in the private part), and deriving a concrete type from an interface
doesn't change that.
We tried to define a special kind of interface that could be used in the
private part in exchange for a promise never to add such an interface to a
descendant of the private type. It didn't work out very well.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-27 7:17 ` Randy Brukardt
@ 2018-01-27 9:33 ` Dmitry A. Kazakov
2018-01-29 23:08 ` Randy Brukardt
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-01-27 9:33 UTC (permalink / raw)
On 2018-01-27 08:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4g15r$1s60$1@gioia.aioe.org...
> ...
>> type Controlled is abstract new <anonymous> with private;
>
> This unfortunately doesn't fix anything. An interface never can be hidden
> (only in the private part), and deriving a concrete type from an interface
> doesn't change that.
But the interface is anonymous, it cannot be referenced in any way
anywhere. It is mentioned only to be inherited from by a named interface.
<anonymous>
/ \
Controlled Controlled_Interface
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-27 9:33 ` Dmitry A. Kazakov
@ 2018-01-29 23:08 ` Randy Brukardt
2018-01-30 8:31 ` Dmitry A. Kazakov
0 siblings, 1 reply; 15+ messages in thread
From: Randy Brukardt @ 2018-01-29 23:08 UTC (permalink / raw)
You mean sort of like "universal_controlled"? As previously noted, that
might work for streams (and maybe pools),but controlled usually carries
components along as well, so an interface (which cannot have components) is
a bad match.
Randy.
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4hh1n$1qao$1@gioia.aioe.org...
> On 2018-01-27 08:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p4g15r$1s60$1@gioia.aioe.org...
>> ...
>>> type Controlled is abstract new <anonymous> with private;
>>
>> This unfortunately doesn't fix anything. An interface never can be hidden
>> (only in the private part), and deriving a concrete type from an
>> interface
>> doesn't change that.
>
> But the interface is anonymous, it cannot be referenced in any way
> anywhere. It is mentioned only to be inherited from by a named interface.
>
> <anonymous>
> / \
> Controlled Controlled_Interface
>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-29 23:08 ` Randy Brukardt
@ 2018-01-30 8:31 ` Dmitry A. Kazakov
2018-01-30 22:02 ` Randy Brukardt
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-01-30 8:31 UTC (permalink / raw)
On 30/01/2018 00:08, Randy Brukardt wrote:
> You mean sort of like "universal_controlled"?
No, that would require a common base for old Ada.Finalization.Controlled
and new Controlled_Interface. no that this is undesired, but it was
rejected already. So the idea is an anonymous base, with the name nobody
dare to call. (:-))
> As previously noted, that
> might work for streams (and maybe pools),but controlled usually carries
> components along as well, so an interface (which cannot have components) is
> a bad match.
That is an implementation detail. There is no components officially, so
it is up to the compiler designer to stuck these somewhere and take care
of the cases when both Ada.Finalization.Controlled and
Controlled_Interface are inherited from.
BTW, I am not a fan of keeping lists of controlled objects and the rules
to finalize objects implicitly. IMO it is a misfeature which adds no
safety, just overhead. If Controlled_Interface would drop these rules I
would be only happy. Then Controlled_Interface could be an interface
without messy postmortem finalization rules, which would apply only if
Ada.Finalization.Controlled inherited.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-30 8:31 ` Dmitry A. Kazakov
@ 2018-01-30 22:02 ` Randy Brukardt
2018-01-31 15:05 ` Dmitry A. Kazakov
0 siblings, 1 reply; 15+ messages in thread
From: Randy Brukardt @ 2018-01-30 22:02 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4pah6$1gan$1@gioia.aioe.org...
> On 30/01/2018 00:08, Randy Brukardt wrote:
>> You mean sort of like "universal_controlled"?
>
> No, that would require a common base for old Ada.Finalization.Controlled
> and new Controlled_Interface. no that this is undesired, but it was
> rejected already. So the idea is an anonymous base, with the name nobody
> dare to call. (:-))
>
>> As previously noted, that
>> might work for streams (and maybe pools),but controlled usually carries
>> components along as well, so an interface (which cannot have components)
>> is
>> a bad match.
>
> That is an implementation detail. There is no components officially, so it
> is up to the compiler designer to stuck these somewhere and take care of
> the cases when both Ada.Finalization.Controlled and Controlled_Interface
> are inherited from.
Right, but implementing "implicit components" this way is the same work as
supporting full multiple inheritance -- the components couldn't be at a
fixed location in the object and you would have to use dispatching or
something similar to find them. If you're going to implement that sort of
thing, it would be criminal not to support it generally for all types -- and
then you don't need a Controlled_Interface at all (or any other interface,
for that matter).
Interfaces keep the runtime cost of multiple inheritance to solely dynamic
dispatching. Pretty much everything else works the same as it always did,
without other overhead. But if you are going to support general multiple
inheritance -- implicit or explicit -- it has a distributed cost that makes
all component accesses slower (at least, anything that could be used in
multiple inheritance).
> BTW, I am not a fan of keeping lists of controlled objects and the rules
> to finalize objects implicitly. IMO it is a misfeature which adds no
> safety, just overhead. If Controlled_Interface would drop these rules I
> would be only happy. Then Controlled_Interface could be an interface
> without messy postmortem finalization rules, which would apply only if
> Ada.Finalization.Controlled inherited.
Huh? If there is no implicit finalization, then there is no need for
controlled types at all, as they serve no purpose. (If you want to
explicitly finalize things, you can define any subprogram for that purpose.
You could even call it "Finalize". And if you want an interface like that,
write it yourself.) The only reason that there is a predefined type is to
get the "magic" behavior. And that behavior is designed so that every object
gets finalized. An abstraction that only finalizes when it is convinient is
not interesting in an Ada context - it would be riddled with holes and
composition would scary.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-30 22:02 ` Randy Brukardt
@ 2018-01-31 15:05 ` Dmitry A. Kazakov
2018-02-01 0:17 ` Randy Brukardt
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-01-31 15:05 UTC (permalink / raw)
On 30/01/2018 23:02, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4pah6$1gan$1@gioia.aioe.org...
>> On 30/01/2018 00:08, Randy Brukardt wrote:
>>> You mean sort of like "universal_controlled"?
>>
>> No, that would require a common base for old Ada.Finalization.Controlled
>> and new Controlled_Interface. no that this is undesired, but it was
>> rejected already. So the idea is an anonymous base, with the name nobody
>> dare to call. (:-))
>>
>>> As previously noted, that
>>> might work for streams (and maybe pools),but controlled usually carries
>>> components along as well, so an interface (which cannot have components)
>>> is
>>> a bad match.
>>
>> That is an implementation detail. There is no components officially, so it
>> is up to the compiler designer to stuck these somewhere and take care of
>> the cases when both Ada.Finalization.Controlled and Controlled_Interface
>> are inherited from.
>
> Right, but implementing "implicit components" this way is the same work as
> supporting full multiple inheritance -- the components couldn't be at a
> fixed location in the object and you would have to use dispatching or
> something similar to find them. If you're going to implement that sort of
> thing, it would be criminal not to support it generally for all types -- and
> then you don't need a Controlled_Interface at all (or any other interface,
> for that matter).
There would be no components unless Ada.Finalization.Controlled inherited.
When inherited from Controlled_Interface only, all checks if to call
Initialize, Finalize, Adjust will be static. No lists of objects.
>> BTW, I am not a fan of keeping lists of controlled objects and the rules
>> to finalize objects implicitly. IMO it is a misfeature which adds no
>> safety, just overhead. If Controlled_Interface would drop these rules I
>> would be only happy. Then Controlled_Interface could be an interface
>> without messy postmortem finalization rules, which would apply only if
>> Ada.Finalization.Controlled inherited.
>
> Huh? If there is no implicit finalization, then there is no need for
> controlled types at all, as they serve no purpose. (If you want to
> explicitly finalize things, you can define any subprogram for that purpose.
"Implicit" meant called upon implicit destruction, e.g. when access
types go out of the scope. That thing is not needed. I don't see other
reason for the Controlled_Interface to induce hidden components.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-01-31 15:05 ` Dmitry A. Kazakov
@ 2018-02-01 0:17 ` Randy Brukardt
2018-02-01 9:03 ` Dmitry A. Kazakov
0 siblings, 1 reply; 15+ messages in thread
From: Randy Brukardt @ 2018-02-01 0:17 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4sm09$126n$1@gioia.aioe.org...
> On 30/01/2018 23:02, Randy Brukardt wrote:
...
>> Huh? If there is no implicit finalization, then there is no need for
>> controlled types at all, as they serve no purpose. (If you want to
>> explicitly finalize things, you can define any subprogram for that
>> purpose.
>
> "Implicit" meant called upon implicit destruction, e.g. when access types
> go out of the scope. That thing is not needed. I don't see other reason
> for the Controlled_Interface to induce hidden components.
(1) Subpools and mutable types also need lists of some sort to properly do
finalization.
(2) The reason for the "out of scope" rules is so that Finalization can be
used for resource allocation beyond simply memory management. For instance,
to return device (handles) to the OS when they won't be used any more. We
felt that there shouldn't be any leaks in that.
(3) I think you would have to ban nested access types (that can go out of
scope before program end) that designate type with parts of this kind of
controlled type, lest the allocation of such objects lead to guarenteed
storage leaks (one doesn't want to use Unchecked_Deallocation if they don't
have to).
(4) Chains for all controlled objects work best with exception handling, as
it isn't necessary to enter every scope to try to clean up objects, and in
particular, one doesn't have to deal with the horror of partially
initialized objects (whose initialization was interrupted by an exception).
To use your static implementation, you also have to use a static
implementation of exceptions, and somehow keep track of initialization of
objects (and every part of such objects) in each scope. It's possible (since
AdaCore has managed it), but it's fiendishly complex and definitely beyond
what I can do. Adopting rules that only AdaCore has enough smarts to
implement would likely ensure that there never will be any other competing
implementation. I think that's bad policy; even if no other implementation
appears, closing the door seems like the wrong way to go.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-01 0:17 ` Randy Brukardt
@ 2018-02-01 9:03 ` Dmitry A. Kazakov
2018-02-01 23:47 ` Randy Brukardt
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-02-01 9:03 UTC (permalink / raw)
On 01/02/2018 01:17, Randy Brukardt wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:p4sm09$126n$1@gioia.aioe.org...
>> On 30/01/2018 23:02, Randy Brukardt wrote:
> ...
>>> Huh? If there is no implicit finalization, then there is no need for
>>> controlled types at all, as they serve no purpose. (If you want to
>>> explicitly finalize things, you can define any subprogram for that
>>> purpose.
>>
>> "Implicit" meant called upon implicit destruction, e.g. when access types
>> go out of the scope. That thing is not needed. I don't see other reason
>> for the Controlled_Interface to induce hidden components.
>
> (1) Subpools and mutable types also need lists of some sort to properly do
> finalization.
No, they need not. The rule would be that all explicitly allocated
objects of Controlled_Interface must be explicitly deallocated.
> (2) The reason for the "out of scope" rules is so that Finalization can be
> used for resource allocation beyond simply memory management. For instance,
> to return device (handles) to the OS when they won't be used any more. We
> felt that there shouldn't be any leaks in that.
I don't see how the feature would help. The only practical case when it
takes effect is when exiting from the program. At that point it does not
matter anyway.
> (3) I think you would have to ban nested access types (that can go out of
> scope before program end) that designate type with parts of this kind of
> controlled type, lest the allocation of such objects lead to guarenteed
> storage leaks (one doesn't want to use Unchecked_Deallocation if they don't
> have to).
Of course I would let them leak. No implicit deallocation.
> (4) Chains for all controlled objects work best with exception handling, as
> it isn't necessary to enter every scope to try to clean up objects, and in
> particular, one doesn't have to deal with the horror of partially
> initialized objects (whose initialization was interrupted by an exception).
It is always a controlled object that goes out the scope. All
dynamically allocated controlled objects are in some kind of controlled
container or other controlled structure responsible to deallocate them.
Everything ultimately hooked on some scoped controlled object. That is
the only sane design, IMO.
> To use your static implementation, you also have to use a static
> implementation of exceptions, and somehow keep track of initialization of
> objects (and every part of such objects) in each scope.
Then the scope can maintain a list of objects it initialized. I see no
need to corrupt the object representation with list pointers in order to
merely roll back the stack.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-01 9:03 ` Dmitry A. Kazakov
@ 2018-02-01 23:47 ` Randy Brukardt
2018-02-02 6:59 ` Niklas Holsti
2018-02-02 8:46 ` Dmitry A. Kazakov
0 siblings, 2 replies; 15+ messages in thread
From: Randy Brukardt @ 2018-02-01 23:47 UTC (permalink / raw)
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:p4ul5c$582$1@gioia.aioe.org...
> On 01/02/2018 01:17, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:p4sm09$126n$1@gioia.aioe.org...
>>> On 30/01/2018 23:02, Randy Brukardt wrote:
>> ...
>>>> Huh? If there is no implicit finalization, then there is no need for
>>>> controlled types at all, as they serve no purpose. (If you want to
>>>> explicitly finalize things, you can define any subprogram for that
>>>> purpose.
>>>
>>> "Implicit" meant called upon implicit destruction, e.g. when access
>>> types
>>> go out of the scope. That thing is not needed. I don't see other reason
>>> for the Controlled_Interface to induce hidden components.
>>
>> (1) Subpools and mutable types also need lists of some sort to properly
>> do
>> finalization.
>
> No, they need not. The rule would be that all explicitly allocated objects
> of Controlled_Interface must be explicitly deallocated.
Yes, but you need a list to explicitly deallocate a subpool (as there are
many objects in the subpool). Or you could just ban the use of subpools, but
that's madness.
>> (2) The reason for the "out of scope" rules is so that Finalization can
>> be
>> used for resource allocation beyond simply memory management. For
>> instance,
>> to return device (handles) to the OS when they won't be used any more. We
>> felt that there shouldn't be any leaks in that.
>
> I don't see how the feature would help. The only practical case when it
> takes effect is when exiting from the program. At that point it does not
> matter anyway.
It does if the underlying manager is primitive (as some RTOSes are) and
there is no automatic closing of handles. (That was the case on CP/M and
early MS-DOS, if one left files open when a program exited, they never got
closed at all. Which could lead to data loss or resource exhaustion.)
>> (3) I think you would have to ban nested access types (that can go out of
>> scope before program end) that designate type with parts of this kind of
>> controlled type, lest the allocation of such objects lead to guarenteed
>> storage leaks (one doesn't want to use Unchecked_Deallocation if they
>> don't
>> have to).
>
> Of course I would let them leak. No implicit deallocation.
OK, but that's not the way Ada handles types with Storage_Size specified.
I'd rather they were illegal (most of the accessibility madness comes from
allowing such types, and they're nearly useless).
>> (4) Chains for all controlled objects work best with exception handling,
>> as
>> it isn't necessary to enter every scope to try to clean up objects, and
>> in
>> particular, one doesn't have to deal with the horror of partially
>> initialized objects (whose initialization was interrupted by an
>> exception).
>
> It is always a controlled object that goes out the scope. All dynamically
> allocated controlled objects are in some kind of controlled container or
> other controlled structure responsible to deallocate them. Everything
> ultimately hooked on some scoped controlled object. That is the only sane
> design, IMO.
>
>> To use your static implementation, you also have to use a static
>> implementation of exceptions, and somehow keep track of initialization of
>> objects (and every part of such objects) in each scope.
>
> Then the scope can maintain a list of objects it initialized. I see no
> need to corrupt the object representation with list pointers in order to
> merely roll back the stack.
That's what I called "fiendishly complex". Sure, it can be done, but you
have to have a handler in every master with none trivial objects (regardless
of whether there is any explicit exception handlers, of even if there can
be). With the exception handing in our compiler, that would be a horrible
drag on performance even if no handlers were used (state snapshots would be
needed for each implicit handler, and handlers block optimizations as well,
so a lot of unneeded checks wouldn't be identified).
The only practical way to that is similar to the way that AdaCore does that
(for both finalization and exception handling), which would be a 2-3 man
year effort for any compiler vendor that isn't already using that scheme (so
far as I know, that's most of the non-AdaCore vendors).
And I doubt that even the AdaCore scheme quite matches to your goals. Plus
the lack of safety (there now are many ways to get skip finalization on
objects), I don't see anyone being very interested. It makes more sense,
honestly, to support full multiple inheritance.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-01 23:47 ` Randy Brukardt
@ 2018-02-02 6:59 ` Niklas Holsti
2018-02-02 22:20 ` Randy Brukardt
2018-02-02 8:46 ` Dmitry A. Kazakov
1 sibling, 1 reply; 15+ messages in thread
From: Niklas Holsti @ 2018-02-02 6:59 UTC (permalink / raw)
On 18-02-02 01:47 , Randy Brukardt wrote:
[about finalization, etc., with Dmitry A. Kazakov]
> The only practical way to that is similar to the way that AdaCore does that
> (for both finalization and exception handling), [...]
>
> And I doubt that even the AdaCore scheme quite matches to your goals. Plus
> the lack of safety (there now are many ways to get skip finalization on
> objects),
I ask for clarification: do you mean that AdaCore's finalization methods
allow finalization to be skipped (which would be bad), or that skips
could happen if Dmitry's suggestions were to be adopted?
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-01 23:47 ` Randy Brukardt
2018-02-02 6:59 ` Niklas Holsti
@ 2018-02-02 8:46 ` Dmitry A. Kazakov
2018-02-02 9:31 ` Niklas Holsti
1 sibling, 1 reply; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-02-02 8:46 UTC (permalink / raw)
On 02/02/2018 00:47, Randy Brukardt wrote:
> Yes, but you need a list to explicitly deallocate a subpool (as there are
> many objects in the subpool). Or you could just ban the use of subpools, but
> that's madness.
If anybody wanted a sub-pool he would be responsible to make them work
with his objects.
It is a stupid design anyway. When I must care about bulk deallocation I
must be even more about bulk finalization.
>> I don't see how the feature would help. The only practical case when it
>> takes effect is when exiting from the program. At that point it does not
>> matter anyway.
>
> It does if the underlying manager is primitive (as some RTOSes are) and
> there is no automatic closing of handles. (That was the case on CP/M and
> early MS-DOS, if one left files open when a program exited, they never got
> closed at all. Which could lead to data loss or resource exhaustion.)
I would never implement it that way. I don't know who would. If the OS
does not collect dead resources, a responsible developer would design a
resource manager for that, because most likely the OS handles would not
work the way you described. There will be some obscure limitations
regarding sharing them, contexts where you can create/release them, etc.
The puny implicit finalization won't work anyway.
>> Of course I would let them leak. No implicit deallocation.
>
> OK, but that's not the way Ada handles types with Storage_Size specified.
No problem either. It would be a bounded error. The memory would be
reclaimed as for any plain type, Finalization not called, what you see
is what you get.
> I'd rather they were illegal (most of the accessibility madness comes from
> allowing such types, and they're nearly useless).
I agree. The problem is that the access type is not a proper type with
interfaces and classes. The language cannot manage referential semantics
introduced by the programmer. There is no chance. So, it should leave
that stuff alone.
Give me a plain pointer with no strings attached. And let me use a
full-blown referential type in the contexts where an access type is
expected. That is all, would cut the Ada RM in half, won't it? (:-))
>> Then the scope can maintain a list of objects it initialized. I see no
>> need to corrupt the object representation with list pointers in order to
>> merely roll back the stack.
>
> That's what I called "fiendishly complex". Sure, it can be done, but you
> have to have a handler in every master with none trivial objects (regardless
> of whether there is any explicit exception handlers, of even if there can
> be). With the exception handing in our compiler, that would be a horrible
> drag on performance even if no handlers were used (state snapshots would be
> needed for each implicit handler, and handlers block optimizations as well,
> so a lot of unneeded checks wouldn't be identified).
I don't see why it so. It is trivial to allocate a list head in front of
the stack allocated object rather than inside it.
> The only practical way to that is similar to the way that AdaCore does that
> (for both finalization and exception handling), which would be a 2-3 man
> year effort for any compiler vendor that isn't already using that scheme (so
> far as I know, that's most of the non-AdaCore vendors).
>
> And I doubt that even the AdaCore scheme quite matches to your goals. Plus
> the lack of safety (there now are many ways to get skip finalization on
> objects), I don't see anyone being very interested. It makes more sense,
> honestly, to support full multiple inheritance.
I think almost all programmers are interested in safe initialization and
finalization *with* rollback. This is the most important feature I can
imagine. The present state when initialization and finalization is a
minefield is simply unacceptable.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-02 8:46 ` Dmitry A. Kazakov
@ 2018-02-02 9:31 ` Niklas Holsti
2018-02-02 10:21 ` Dmitry A. Kazakov
0 siblings, 1 reply; 15+ messages in thread
From: Niklas Holsti @ 2018-02-02 9:31 UTC (permalink / raw)
On 18-02-02 10:46 , Dmitry A. Kazakov wrote:
> Give me a plain pointer with no strings attached.
You want to forbid "access String" ??
:-) :-)
--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-02 9:31 ` Niklas Holsti
@ 2018-02-02 10:21 ` Dmitry A. Kazakov
0 siblings, 0 replies; 15+ messages in thread
From: Dmitry A. Kazakov @ 2018-02-02 10:21 UTC (permalink / raw)
On 02/02/2018 10:31, Niklas Holsti wrote:
> On 18-02-02 10:46 , Dmitry A. Kazakov wrote:
>
>> Give me a plain pointer with no strings attached.
>
> You want to forbid "access String" ??
>
> :-) :-)
BTW:
type Text (Length : Natural) is access String (1..Length);
type Instance (Tag : Ada.Tags.Tag) is access Object_Type'Class (Tag);
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Prologue and epilogue aspects
2018-02-02 6:59 ` Niklas Holsti
@ 2018-02-02 22:20 ` Randy Brukardt
0 siblings, 0 replies; 15+ messages in thread
From: Randy Brukardt @ 2018-02-02 22:20 UTC (permalink / raw)
"Niklas Holsti" <niklas.holsti@tidorum.invalid> wrote in message
news:fdighkFpkguU1@mid.individual.net...
> On 18-02-02 01:47 , Randy Brukardt wrote:
>
> [about finalization, etc., with Dmitry A. Kazakov]
>
>> The only practical way to that is similar to the way that AdaCore does
>> that
>> (for both finalization and exception handling), [...]
>>
>> And I doubt that even the AdaCore scheme quite matches to your goals.
>> Plus
>> the lack of safety (there now are many ways to get skip finalization on
>> objects),
>
> I ask for clarification: do you mean that AdaCore's finalization methods
> allow finalization to be skipped (which would be bad), or that skips could
> happen if Dmitry's suggestions were to be adopted?
Only if Dmitry's suggestions were to be adopted. AdaCore uses lists in some
cases, Dmitry wanted to get rid of those cases by saying that they don't
finalize. So far as I'm aware, GNAT does the right thing for Ada 2012 in
every case.
Randy.
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2018-02-02 22:20 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-26 19:56 Prologue and epilogue aspects Dmitry A. Kazakov
2018-01-27 7:17 ` Randy Brukardt
2018-01-27 9:33 ` Dmitry A. Kazakov
2018-01-29 23:08 ` Randy Brukardt
2018-01-30 8:31 ` Dmitry A. Kazakov
2018-01-30 22:02 ` Randy Brukardt
2018-01-31 15:05 ` Dmitry A. Kazakov
2018-02-01 0:17 ` Randy Brukardt
2018-02-01 9:03 ` Dmitry A. Kazakov
2018-02-01 23:47 ` Randy Brukardt
2018-02-02 6:59 ` Niklas Holsti
2018-02-02 22:20 ` Randy Brukardt
2018-02-02 8:46 ` Dmitry A. Kazakov
2018-02-02 9:31 ` Niklas Holsti
2018-02-02 10:21 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox