incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Harrison & Wells" <rahul29112...@gmail.com>
Subject Re: Project informal discussion
Date Tue, 18 Jul 2017 11:21:56 GMT
Actually,I should have provided more details.
Imagine it like this:
Lots of interfaces,e.g,an interface "Class" which will have abstract
methods like putMethod(Method[which will be another
interface]),putField(Field[another interface]),and stuff like that.
Now, let's say we implement all these interfaces(there'll be obviously more
than these 3) for Java,we'll get a Java driver.
The guy who coded the Java driver can now register it into a
"DriverManager",and
the other guy,who wants to use it can just do
something like this:
Driver javaDriver = DriverManager.getDriver("java");
We can now use this javaDriver instance to create stuff like a Class object.
Then we can do:
Class clazz = javaDriver.createClass();
//we get a class implemented by the javadriver,
//so now when we'll make methods and put them on this class
//they'll be java methods
Method psvm = clazz.createMethod(AccessSpecifier.PUBLIC /*An enum*/, "void"
/*return type*/, true /*isStatic*/, "main" /*name*/, "String[] args"
/*Arguments, if any*/);
clazz.putMethod(psvm /*the method*/);
clazz.write(System.out /*Writing to an output stream*/);
The main thing with this approach is that it allows to create many
drivers,and thus we won't have to write our logic separately for,say,Python.
Instead of a java driver, one could just request a python driver.
Without the need of transpilers.
In fact, I guess it can be *used *to make transpilers.
Parse the source code into an abstract syntax tree,iterate over it and
generate some methods and fields for it, and the driver will take care of
the implementation.
So, what do you guys think?

On Tue, Jul 18, 2017 at 11:56 AM, Romain Manni-Bucau <rmannibucau@gmail.com>
wrote:

> Hi
>
> For sources any template engine is great so velocity, freemarker, ..., even
> strings (like cxf client plugin does) so need for a more formal lib is less
> true than for bytecode generation. Eugene (from codelutin not asf) is also
> a great one for sources.
>
> What would add yours? Kind of fear it ends up as a token based api to stay
> powerful which wouldnt be that user friendly at the end (compared to
> templates).
>
> Le 18 juil. 2017 08:22, "Wade Chandler" <wadechandler@apache.org> a écrit
> :
>
> > You should also checkout something like Graal and Truffle
> > https://github.com/graalvm/graal/blob/master/truffle/README.md
> >
> > Wade
> >
> >
> > On Jul 18, 2017 02:01, "Jochen Theodorou" <blackdrag@gmx.org> wrote:
> >
> > > On 18.07.2017 02:53, Harrison & Wells wrote:
> > >
> > >> # I'm just a beginner here, please ignore any stupidities
> > >> So guys, you told me to discuss my project here first.
> > >> Well, I have an idea of making a source code generator.
> > >> There really isn't a source code generation library.And it can be
> done.
> > >> It is really useful,just like BCEL, I think there should be one for
> > >> source.
> > >>
> > >> For example, when one is making a compiler compiler,it will be quite
> > >> handy.
> > >> I haven't written any source at the moment, but when I do,can I start
> my
> > >> packages with org.apache.
> > >> Because,it's gonna be real cool.
> > >>
> > >>
> > > I think you will have to give this a lot more flesh. Right now I can
> > > imagine everything from a simple templating engine up to a compiler
> > > generator like antlr
> > >
> > > bye Jochen
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
> > > For additional commands, e-mail: general-help@incubator.apache.org
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message