On Mar 19, 2:24 am, Maciej Sobczak <see.my.homep...@[EMAIL PROTECTED]
> wrote:
> X : Type;
> Y : Type_Ptr := new Type;
[...]
> For some types I might want to prohibit one of these two ways of
> object creation.
You can't prohibit the object creation itself, but you can make such
an object useless.
> If these two methods are available, then apparently there is a
> difference between them and this difference is not in *where* objects
> are created, but *how long* they are allowed to live.
If you want to control lifetime, you can control either the allocation
lifetime or the functional lifetime; the second is a subset of the
first. As you've pointed out, you don't get a lot of control over
allocation lifetime. But functional lifetime you can control. Here's
how I would approach it.
First, make the utility of your type depend for its function on the
existence of some other object. This likely goes into a constructor
function, but need not. Your type would contain some kind of a weak
accessor, one that doesn't enforce the existence of its referent.
Gate all utility upon the existence of this referent. If the referent
is absent, do nothing or throw an exception, whatever. This check is
cheap; it's that some access value is not null. Use finalization in
the referent to update the accessor value in your type. This gives
you a dependency between objects, regardless of how the referent
object is allocated.
Second, when instantiating the object, make it refer to a sentry
object with block scope. When the sentry object goes out of scope,
your original object will stop working. I frequently use nested
declare/begin/end blocks within subprogram definitions to trigger
sentry finalization.
You'll still have to do***ent that if you want scope lifetime for your
object's utility, you'll have to make it dependent upon a scoped
variable. But at that point the code explicitly captures an intention
for scope lifetime.
Eric
|
