Re: Limited use for limited with?

["Randy Brukardt" <randy@rrsoftware.com>]

"Maciej Sobczak" <see.my.homepage@gmail.com> wrote in message 
news:292dd0bd-1fc4-4715-bb70-7655d0dc04eb@j24g2000yqa.googlegroups.com...
On 29 Wrz, 09:51, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>> No, that makes it (the public interface) more clear. Pointer is an
>> implementation detail to be hidden.
>
>Reference leak is not an implementation detail, it is a very important
>part of the contract.

Dmitry is right, the *reference* ought to be part of the object, so a leak 
is impossible. In any case, using an access type in the specification of 
Register doesn't do anything to say how long the access will be used for, so 
that doesn't help any. (C and C++ interfaces are notorious for this problem: 
there is often no way to tell whether the access needs to remain valid until 
some later time, nor what time that is.)

>No way. There are *many* Registers, meaning that a single object can
>be registered in several registries, not just one. Will you suggest
>passing an array of registries to the constructor? I hope not.

This sounds like chaos, not a design. There is no way to figure out anything 
that happens with callbacks, registered or not. Callbacks are dubious to 
begin with; moreover, when objects need to be registered that should only 
happen with a very small number of places (hopefully one).

Note that Claw uses exactly the design that Dmitry is describing. Each 
Window can be linked into a handful of data structures -- but we use 
Finalize to ensure it is not linked on any when the object is destroyed. The 
alternative of making all of this the client's problem is simply not "the 
Ada way". (It also would have made Claw technical support impossible; we had 
plenty of bizarre problems even with all of the automatic cleanup, some 
because compiler bugs didn't always clean things up. Without that cleanup, 
it would have been total chaos -- it is viritually impossible to manually 
clean up objects when exceptions happen [some are always missed] -- and 
exceptions are *always* happening in an Ada program [especially during 
testing].)

>The problem with your approach is that it tries to bend the design of
>the system in order to work around some language limitation. I prefer
>having it the other way round.

The "design" sounds more like copying bad ideas from some other 
implementation for some other programming language.

>In short, I still don't see a plausible solution to my problem and
>from all poor solutions that I'm aware of, the one I already use seems
>to be the simplest.

When you start with a poor design, it's not surprising you can only find 
poor solutions...

                                Randy.