Re: [Introspector-developers] Happy new year, plan for 2003

[James M. D. <mdu...@ya...>]

Kyle,
I have been thinking about what you said some more,
and have the following points to add :

the reason why we need to be able to create the structure and the
instances separatly in the different target languages is that it is
very difficult to create a generic reader for the ASts. 

Basically we have a data feed and want to create a generic model of
data from the gcc, in a way that we can process it in various
languages.

From this generic meta-model, we should be able to generate and give
the users a simple set of data structures that they can use to
manipulate the data from the gcc. And we should be able to create
instances of them as static snippets of code, or reading them from rdf
files. 

The usage of reflection is great, but only helps if you have an
instance of the give object, with the right class. 

mike

--- Kyle Lahnakoski <ky...@ar...> wrote:
> 
> I will mostly repeat what you said so that I know I understand.
> 
> James Michael DuPont wrote:
>  > the second step will be to document the meta-model in terms of the
>  > common lisp object system CLOS. it is a well understood model that
> has
>  > well defined semantics. I thik that a CLOSGenerator (Like a
>  > java-generator) is the right way forward.
> 
> CLOS may be very good MOP (Meta-Object Protocol) to copy.  It may be
> too 
> flexible; being needlessly complex to handle situations never used. 
> I 
> really do not know much about the CLOS.
> 
>  > But we need to do one more thing :
>  > Thirdly. all the language generators currently describe classes,
>  > the java generator creates classes. but what about objects?
> 
> I am sure that this is not a problem for CLOS.
> 
> It is not a problem for Java either; the reflection API is sufficient
> to 
> create objects and populate their fields.  We may want to add a
> simple 
> API on top of it for some more-commonly used operations. (assuming 
> anything is even built in Java)
> 
>  > we nee an JavaInstance generator : the ability to create code that
>  > represents instances of java, in terms of the generated classes.
> Also
>  > we need to be able to read in instances from an XML/RDF feed.
> 
> So, I guess you are saying we need a standard MOP, probably like
> CLOS. 
> This standard MOP should be able to handle the majority of languages 
> introspector plans on inspecting.
> 
> Will this standard MOP will take the form of a document that humans
> can 
> read?  Or are we going to have it hidden in implementation code?  :)
> 
>  > so to summarize :
>  >
>  > 1. support the creation of meta-model from the rdf input from the
> gcc.
>  >  : meta-circularity
>  >
>  > 2. support the generation of CLOS classes
>  >  : using a well defined class model to document ours
>  >
>  > 3. support the generation of source code for instances of
>  > Java, perl, CLOS, sql from the rdf, in terms of the generated
> classses.
>  >   : creation of literal source code that creates instances from
> the
>  > literals (constants)
>  >
>  > 4. Support reading of the rdf files and generation of these
> instances
>  > as programm code.
>  >   : creation of source code that creates instances from a variable
> file
>  > of data.
> 
> So introspector plans to:
> 
> 	Read in nodes from gcc
> 	Build an internal representation (functions, and classes)
> 	Serialize to various languages
> 
> In essence we will have a language conversion facility.
> 
> 
> What language is this all written in?  Perl?
> 
> 
> Thanks
> 
> 
> 
>
----------------------------------------------------------------------
> Kyle Lahnakoski                                      
> ky...@ar...
> (416) 892-7784                                    Arcavia Software
> Ltd
> 
> 


=====
James Michael DuPont
http://introspector.sourceforge.net/

__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com