So, back to the topic of virtual methods. I have some ideas, questions, =
and
comments...
-=3D Virtual Methods: Loading into Memory =3D-
Jean-Pierre and I talked about this previously and agreed (if I remember
correctly) that implementations of virtual methods should only be loaded
into memory if they are not overrided by a descendant. This is because =
the
overrided VI might not have its dependencies met, or would just add =
extra
overhead. This means that we cannot use Static VI Refnum constants (LV7
feature), or equivalent mechanism of statically linking in our dynamic
method VIs to guarantee that they are in memory (this allows opening
references by name, rather than by path). So we need some other =
mechanism
of locating them at run-time. We could first look for them in a known
location beneath the class folder (like ./Public), and second look in =
the
same location as the VI that's looking for them ( <Current VI's Path> +
<../"ClassName MethodName.vi"> ). The latter would be used in case the =
app
were built into an application or packaged for distribution. I have =
posted
an example of this here:
http://www.openg.org/tiki/tiki-download_wiki_attachment.php?attId=3D25
-=3D Virtual Methods: Interface Check =3D-
Should a constructor check (at object instantiation time) to make sure =
that
its child implementation of virtual methods have the correct interface? =
This
means that the constructor might have to perform some connector pane =
check
of all the method VIs that it finds in the child class. This requires
loading them all into memory. However, what if the child class's
constructor instead passed an interface descriptor down to the parent's
constructor that contained connector pane info (control connector pane
positions and datatypes) for all its method VIs, along with the method =
names
and paths? Then we could type-check at object construction time without
actually loading the virtual methods at that time.
-=3D Virtual Methods: Object Instantiation =3D-
When a Class constructor is called by its Child's constructor, it =
receives
(either as an input or by some indirect mechanism) a list of methods =
that
have been implemented by the classes descendants. It appends to the =
list
all of its methods whose names are not already in the list (this is how
methods are overrided). Then, it passes this list to its Parent's
constructor. This process continues up the class hierarchy until the =
root
class is constructed.
Any thoughts?
-Jim
|
