| object suggestion for future IDL versions [message #15878] |
Mon, 21 June 1999 00:00 |
John Persing
Messages: 4
Registered: June 1999
|
Junior Member |
|
|
I don't know if anybody else has had this problem, but it occurs with
objects that take advantage of inheritance. The object may take advantage
of the inherited methods by using the notation
self->method_name, arg1, arg2, etc
But if the new object redefines any of the inherited methods (for example
"assign"), it cannot make reference to the inherited method. So say our new
object is just like the inherited object, except that when the data is
changed, a time stamp is placed on the data so
PRO dat_new__define
struct = {dat_new, time_stamp:'', INHERITS dat_old}
END
can define our new object. Ideally, I think, we would want to extend the
assign method like this
PRO dat_new::assign, field_string, value
self->assign, field_string, value
self.time_string = STRING(SYSTIME())
END
I am not exactly sure if this is the way objects _should_ work, but this is
the way I _want_ them to work. The work around is to put an extra level of
abstraction in the definitions of the parent methods, or provide the new
object with a new method name. The former solution leads to a duplication
of every method, and more dangerously, two ways to do everything. The
latter solution presents the even more dangerous possibility that the parent
object method is available to edit the data without updating the time stamp.
So I have settled on the solution of cut and pasting the parent definition
of the method and making the one-line change that I need to in the new
method.
--
}3 John Persing }3
http://www.frii.com/~persing persing@frii.com
Half of all Americans earn less than the median income!!!!!!
|
|
|
|
| Re: object suggestion for future IDL versions [message #16027 is a reply to message #15878] |
Mon, 21 June 1999 00:00  |
davidf
Messages: 2866
Registered: September 1996
|
Senior Member |
|
|
John Persing (persing@frii.com) writes:
> I don't know if anybody else has had this problem, but it occurs with
> objects that take advantage of inheritance. The object may take advantage
> of the inherited methods by using the notation
>
> self->method_name, arg1, arg2, etc
>
> But if the new object redefines any of the inherited methods (for example
> "assign"), it cannot make reference to the inherited method.
Not so. If a method is called on an object, IDL searches the
current class for a method of that name. Failing to find it,
IDL search all the inherited classes in the order in which they
are inherited for the method.
Providing a method of the same name of a superclass method
is called method overriding and is supported by the above
mechanism. But you can always call a specific superclass
method by directly specifying the superclass name in the
method call.
> PRO dat_new__define
> struct = {dat_new, time_stamp:'', INHERITS dat_old}
> END
>
> can define our new object. Ideally, I think, we would want to extend the
> assign method like this
>
> PRO dat_new::assign, field_string, value
> self->assign, field_string, value
> self.time_string = STRING(SYSTIME())
> END
You have it almost right. But the ASSIGN method should be
called like this:
self->DAT_OLD::assign, field_string, value
Cheers,
David
--
David Fanning, Ph.D.
Fanning Software Consulting
Phone: 970-221-0438 E-Mail: davidf@dfanning.com
Coyote's Guide to IDL Programming: http://www.dfanning.com/
Toll-Free IDL Book Orders: 1-888-461-0155
[Note: This follow-up was e-mailed to the cited author.]
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
