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

[Frank V. C. <fr...@co...>]

Christophe Prud'homme wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > (defclass corelinux::SomeClass
> >       (defproperty "Value" : native=int)
> >       (defmetaproperty "Parents" {MetaClassRoot})
> > )
> Ok sounds cool !
> actually I was thinking about doing this through macros
> 
> PROPERTY( int Value READ getValue WRITE setValue );
> getValue() and setValue() are getters and setters

My assumption was that ALL values have get and set methods (making the
declaration redundant). There needs to be a consistent reflection
interface for frameworks (such as Persist) to do their thing. This would
be no different than generating the "getXXXX" and "setXXXX" expansions
found in MetaType.hpp today. We can use a form of name mangling to
ensure we have the interface standards for property types without
colliding with interface the developer has declared/defined.

> 
> > 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).
> yes that was wht I wanted to do with parser+macros
> the DEFINE_METACLASS would have been only META_CLASS and used inside the class
> then the parser recognise the symbol and generate the meta class information
> Now if new properties are defined they are parsed also and the mcd is
> generated automatically.
> 
> > This is the first point, I will wait before raising any others.
> > Thoughts?
> Your system seems to be cleaner/simpler.
> However in the system I was thinking the parser would have been a stripped
> c++ parser therefore the DEFINE_METACLASS( class ); would be only
> DEFINE_METACLASS (no arg) and the parser would generate the basic meta
> informations (class::getClassName() for example ) on the class directly from
> the header file. So any changes in the header file is caugth.

I'm against parsing the C++ stuff at all, personally. The reasons being
that:

* It removes control of what data members or methods are "exposed" in
the reflective declaration unless we require them to add more macros to
the header files, which is what I thought we wanted to get away from? 

* It allows us to get VERY expressive in the clmc file declarations:

(defmethod (virtual | static | none) ....)
(defmetamethod (virtual | static | none) ....)

etc.

Also, note in the example that I gave that "SomeClass" was NOT derived
from anything, but the "(defclass SomeClass)" had a "Parents" defined.
MetaClasses don't neccessarily follow C++ class derivation graphs, and
while I anticipate that most WILL, it is not implicit. Come to think of
it, you would propably want something like:

(MetaSomeClassClass associates SomeClass
	(property "Value" : native=int)
	(metaproperty "Parents" {MetaClassRoot})
)

which would make MetaSomeClassClass a first class object that SomeClass
would use through the minor macro expansions, instead of making it a
nested class. (Note the lack of namespace assumes "corelinux::").
	

There may also be cases where we want PURE metaclasses defined, that
will live in the ontology for various reasons. For this refer to classes
programming.

> 
> Moreover what if the class is a template for example? don't you need a c++
> parser to ensure that the class definition is correct when you generate the
> mcd file ?
> 
> template<typename T>
> class A
> {
>  DEFINE_METACLASS( A<T> );
>  blah.
> };
> 
> now how do you deal with this in the clmc file ? that is how do you
> synchronize the class definition with the clmc file and generated mcd file ?
> 

I would need to research meta object protocol with the use of templated
classes. My first thought is that we don't work with templatized classes
at this point.


> best regards
> C.
> - --
>   Christophe Prud'homme                 |
>   MIT, 77, Mass Ave, Rm 3-243           |  A classic is something that
>   Cambridge MA 02139                    |  everyone wants to have read and
>   Tel (Office) : (00 1) (617) 253 0229  |  nobody wants to read.
>   Fax (Office) : (00 1) (617) 258 8559  |  -- Mark Twain,
>   http://augustine.mit.edu/~prudhomm    |  "The Disappearance of Literature"
>   ICQ UIN: 24560867 Alias: Jesunix      |
>                           Following the hacker spirit
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.0.4 (GNU/Linux)
> Comment: For info see http://www.gnupg.org
> 
> iEYEARECAAYFAjqWOjoACgkQoY+0C9S+FFCkVACfTRGVHgAttgCcn2Ftg0aWcuJN
> jhEAmgOHfbNF178GWIwfxprujwlO1yqI
> =UMer
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> Corelinux-develop mailing list
> Cor...@li...
> http://lists.sourceforge.net/lists/listinfo/corelinux-develop

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