R
Rainer Weikusat
Negative one first: Destructors of superclasses aren't executed
automatically when an instance of a subclass with a destructor of its
own is destroyed. This implies that, in order to derive a class from
some other class, knowledge about the implementation of all ancestors
of the new class is required because a suitable order and mechanism to
cause superclass destructors to be executed needs to be worked out.
The positive one: A class is created by associating a reference to an
object of some type with a package. This is accomplished by calling
the bless-subroutine with suitable arguments. Because this is just an
ordinary runtime-operation, references which are already blessed into
a particular package can be 're-blessed' into a different package in
order to become an instance of a different class.
Example where this is useful: For a 'firewall-configuring application'
I need to manage sets of 'IP addresses' which are composed of objects
representing a single address and objects representing an address
range. An operation I need to perform on two such sets is to do an
ordered merge of them. This requires being able to merge any two
objects making up a continuous range into an equivalent, single range
object. If I can do destructive merging (usual case), this is
implemented by calling a method named change_addrs on the object
'containing' the new end-address of the combined range. If this
happens to be an object representing a single address, the method
transparently morphs that into a range object.
automatically when an instance of a subclass with a destructor of its
own is destroyed. This implies that, in order to derive a class from
some other class, knowledge about the implementation of all ancestors
of the new class is required because a suitable order and mechanism to
cause superclass destructors to be executed needs to be worked out.
The positive one: A class is created by associating a reference to an
object of some type with a package. This is accomplished by calling
the bless-subroutine with suitable arguments. Because this is just an
ordinary runtime-operation, references which are already blessed into
a particular package can be 're-blessed' into a different package in
order to become an instance of a different class.
Example where this is useful: For a 'firewall-configuring application'
I need to manage sets of 'IP addresses' which are composed of objects
representing a single address and objects representing an address
range. An operation I need to perform on two such sets is to do an
ordered merge of them. This requires being able to merge any two
objects making up a continuous range into an equivalent, single range
object. If I can do destructive merging (usual case), this is
implemented by calling a method named change_addrs on the object
'containing' the new end-address of the combined range. If this
happens to be an object representing a single address, the method
transparently morphs that into a range object.