RE: OpenGOOP Inheritance Requirements Model

[<Bjo...@si...>]

I think it would be nice if it was possible to create a new and empty class
from the palette. Then use the wizard to "fill in the blanks" and all the
other stuff. Maybe not that usefull for top level vis?

> -----Original Message-----
> From: Jim Kring [mailto:ji...@ji...]
> Sent: 17. desember 2003 08:26
> To: OpenGToolkit-Developers
> Subject: OpenGOOP Inheritance Requirements Model
> 
> 
> Hello All,
>  
> I am working hard to get OpenGOOP Inheritance ready for an 
> alpha release.
> The class template and some prototype class generator/linker tools are
> almost finished.  As such, this is a good time to ping the 
> rest of the OpenG
> developers, since you will probably be the first users of OpenGOOP
> Inheritance.  I want to get some feedback from you all on the 
> high-level
> requirements for OpenGOOP Inheritance.  Basically, I want to 
> know what you
> all want out of a "Wizard" -- the tools for automated class 
> generation,
> development, maintenance, documentation, etc.  There are two 
> main goals that
> I am shooting for: (1) programmatic interface to the wizard 
> and (2) make the
> design modular by utilizing a plug-in framework based on OpenGOOP
> Inheritance abstract classes.  Goal #2 won't be realized 
> until later, once
> the OpenGOOP Inheritance design stabilizes.  Goal #1 is the short-term
> focus.  But, before the programmatic interface can be 
> developed, we need to
> define the features that you all want.  So, take a look at 
> this list an
> please feel free to comment.
>  
> Regards,
>  
> -Jim
>  
>  
> OpenGOOP Inheritance Requirements Model
>  
> -= Constraints =-
>  
> FR_010 - Utilize OpenGOOP for Classes 
> OpenGOOP Inheritance should use LV2 Globals Called by 
> Reference, as the
> individual class data stores.  An inheritance hierarchy is created by
> aggregating the instances of the individual classes in the inheritance
> hierarchy.  Children will access the data of thier parents 
> through special
> "core" VIs provided by the parents.
>  
> FR_011 - The "core" of the class may be easily upgraded by 
> class developers.
> 
> The Core of the class are those parts that are not customized by class
> developers.  The core does not contain (but may depend upon) 
> VIs or TypeDefs
> that defines the structure of the class.  The Core is the 
> "glue" that holds
> the class together.  Replacing the Core of the class (e.g with a newer
> version) should be transparent to the class developer.  Also, 
> there may be
> many types of Cores that are optimized for certain type of 
> performance (e.g.
> instanciation speed, access speed, data size, etc).
>  
> FR_012 - The "Common Core" should be as small as possible, initially. 
> The "Common Core" is the portion of the core that all 
> OpenGOOP Inheritance
> classes depend upon.  Initially, this should be kept as small 
> as possible,
> since all classes depend upon it.  Initially Common Core 
> components will be
> stored in each Class's "Core" folder (and be linked within 
> the classes own
> namespace).
>  
> FR_013 - Wizard should provide plug-in interfaces that are 
> implemented by
> OpenGOOP Inheritance subclasses. 
> This provides two benefits.  First, it allows us to eat our 
> own dog food.
> Second, it allows users to create new plug-ins and features 
> of the Wizard --
> this is of huge importance to the project.  These interfaces 
> should be well
> documented and templates should be made available.
>  
> -= Features =-
>  
> Class Creation:
>  
> FR_001 - Classes can be created from other classes (as a copy).
>  
> FR_013 - Classes can be created from class meta information.
> Classes can be created from class meta information such as 
> class name, data
> members, methods, etc.; perhaps in an XML file or similar.
>  
> 
> Class Deployment:
>  
> FR_002 - Classes can be "built" into Apps 
> Classes should be able to be built.  This means that the source may be
> consolidated into a single folder (or LLB).
>  
> FR_003 - Classes can be "name mangled" 
> Classes can be name mangled with a suffix such that the name 
> appears like
> *__opengtool.vi
> 
> Class Documentation:
>  
> FR_006 - Class meta information (documentation) may be 
> exported to file. 
> 
> Class Management:
>  
> FR_004 - Classes may be renamed 
> Renaming should also take into consideration whether 
> dependant classes are
> to be relinked to the renamed class.
>  
> FR_005 - Classes may be relinked to a new parent class 
> 
> FR_009 - Class "icon banners" may be updated automatically. 
> A VI "icon banner" is often used accross the top of all VIs 
> within a class.
> This "icon banner" is just a string that represents the class name.
> 
> Class Visualization:
>  
> FR_007 - Class inheritance hierarchy may be visualized
> There should be a way to visualize the relationships between 
> classes in an
> inheritance hierarchy
>  
> FR_008 - Class structure may be visualized. 
> There should be a way to visualize a class's structure.  This 
> should show
> the various members (public, protected, and private data) and 
> methods.  The
> visualization tool should group by type (modifier): e.g. 
> public, virtual,
> etc).
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> _______________________________________________
> OpenGToolkit-Developers mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengtoolkit-developers
>