From: Jim K. <ji...@ji...> - 2003-10-18 00:35:15
|
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 |