Thread: [Corelinux-develop] Some details of MetaClass parser

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

It might be helpful to reiterate why the MetaType/MetaClass information
is alive in the first place:

1. It enables developers a way to reason with objects without knowing
the details of the class itself. This is enabled through the use of the
method and type information, as well as subclass (parent/child)
relationships.

2. The ability to provide the frameworks (Library, Persist, etc.) the
means to be more effective in the capability it can deliver. By removing
the bond between interface and compilation time, the frameworks are more
flexible.

3. It is similar to the work I was progressing with in knowledge
representation, so I thought it cool (mainly for the above two reasons).

And some facts:

1. You can build the metatype/metaclass instance at run-time. We did it
at implementation time because it was convenient to me (as it was in my
head and clear as a bell). It is messy and convuluted, and Christophe is
headed in the very right direction.

2. There is a slight overlap between metatype and metaclass, and there
is probably a implementation error in there as well.

3. We are missing a way to describe a relationship (composition or
aggregate) between two or more metaclasses. Without them we are unable
to express semantics that exist on the class (for any number of
reasons), and prevent a full Meta Object Protocol enablement (classless
programming).

So, here is some of what I am proposing and why:

* The MetaClass parser should not generate the C++ class interwoven with
the MetaClass information, but instead stick to the MetaClass
declarations and definitions as extra files. This implies that the
developer has provided the C++ class and has used that information in
formulating the MetaClass declaration file. 

For example:

SomeClass.hpp
-------------

class SomeClass 
{
	DECLARE_METACLASS( SomeClass );

public:

	int	getValue( void ) const;
	void	setValue( const int & );

private:

	int	theValue;
	//
};

SomeClass.cpp
-------------

DEFINE_METACLASS( SomeClass );

// Start user code

SomeClass.clmc (my own syntax for the moment)
--------------

(defclass corelinux::SomeClass 
	(defproperty "Value" : native=int)
	(defmetaproperty "Parents" {MetaClassRoot}) 	
)

the parser reads the clmc file and generates an mci (metaclass include)
and mcd (metaclass definition), such that when DECLARE_METACLASS expands
to (for example)

#include	<MetaClassSomeClass.mci>
// which expands to a inner class and SomeClass statics (such as class
pointer and accessors for it)

And DEFINE_METACLASS expands to include the "mcd" file which is
fundementally what we now have in macros, with the addition that the
initializer adds itself to the Ontology target (in this example
corelinux).

Note1: See the defproperty and defmetaproperty? The former refers to
properties as declared by the user for the class instances, whereas the
defmetaproperty is a relationship for the metaclass instance only. Other
metaproperties could be added that would enable implementation level
semantics to be integrated in for use by the end-user applications.

This is the first point, I will wait before raising any others.
Thoughts?

-- 
Frank V. Castellucci
http://corelinux.sourceforge.net
OOA/OOD/C++ Standards and Guidelines for Linux
http://PythPat.sourceforge.net
Pythons Pattern Package

Thread: [Corelinux-develop] Some details of MetaClass parser

corelinux-develop