If adding the ooRexx destructor UNINIT to the root
class, then one can safely forward the UNINIT message
to the superclass without the need to determine whether
that paritcular method exists there.
(Very much like the constructor INIT.)
Logged In: YES
This is a BAD idea. Objects that have an UNIT method cannot
be reclaimed by the garbage collector until the UNIT method
has been executed, and UNIT methods cannot be run at the
point where a garbage collection occurs because it is not
safe to do so. This will result in excessive memory
requirements, and essentially render memory garbage
collection useless. UNINIT methods should only exist on
objects that actually require the UNINIT behavior and this
should not be added for the mere convenience of it.
You seem to have CSS turned off.
Please don't fill out this field.
Logged In: YES
Hmm, if it is a runtime problem, then querying at runtime
whether an UNKNOWN method exists in a superclass that needs
to get invoked should be made easy.
Also, is it assured that those objects possessing an UNKNOWN
method have always all resources available to them at the
time UNKNOWN runs, e.g. references to other objects AND to
their class object (and its superclasses) are not garbage
collected after the last object with UNKNOWN got garbage
This is NOT just a runtime problem. An object that has an
UNINIT method requires special handling by the garbage
collector. The object cannot be garbage collected until the
UNINIT method is run. This means that when the object goes
out of scope, it must be moved over to a special queue for a
pending UNINIT operation, which will not be processed until
some "safe" moment.
If Object has an UNINIT method, then EVERY object just be
placed on the UNINIT queue, and thus NO objects will be
recoverable during a garbage collection cycle. At a
minimum, this will require at least double the memory
currently required by the garbage collector. This also
means recovery operations will become enormously expensive,
because EVERY object on the heap must incur the additional
expense of running a NOP UNIT method.
I don't understand at all your arguments centered around the
UNKNOWN method, but under no circumstances will I support
implementing this feature. UNINIT is a very expensive
operation and should maintain that special place.
Add understanding my request:
If one defines a constructor (INIT) or destructor (UNINIT),
in most cases one wishes to invoke the constructors and
destructors in the superclasses.
Invoking the constructor in the superclass is easy and SAFE:
FORWARD CLASS (super)
The reason why sending an INIT message up the inheritance is
SAFE lies in the fact that the root class Obejct has a
constructor defined. This way it is guaranteed that a
The case with destructors is unfortunately different: if one
defines a destructor, then if one wishes to invoke the
destructor in the superclasses one risks a runtime error, if
no UNINIT method exists in any of the superclasses. Having
a default destructor (UNINIT) in the root class Object would
alleviate this problem, as it does in the case of the
constructor (INIT). It would make programming on the
programmer's side just as easy.
Logged In: YES
UNINIT is a special method that gives the object special status by it's mere presence. It would not be correct for this to be implemented on every object just for the mere convenience of being able to do the forward in any UNINIT method.