Cao, thanks for the nice feedback!
> Do you think if it's good to transform a standalone oxml program to Java code?
> We can map a type to a Java class, map a function to a method etc. That'll
> enable people to integrate oxml code more seamlessly in Java and thus
> encourage
> people to try o-xml out in their projects.
Java transformations are definitely coming. I was experimenting some time
ago with o:XML -> Java using plain XSLT and managed to produce working
code out of a subset of the language constructs. However it ran much
slower than the interpreted code! I put this down to expression evaluation
- using the ObjectBox, expressions are parsed and compiled before the
program is executed. With the transformed code, they had to be parsed and
compiled every time.
Partly for this purpose I created the XSLT parser generator YAPP (see the
documentation page of the web site). Using YAPP, the expressions can be
parsed at the transformation stage, and compiled into straight Java
function calls. That should effectively run shit fast, probably producing
XML faster than almost every other Java XML application, and with a very
small memory footprint.
there's some info on transformations at:
http://www.o-xml.org/docs/tools.html
(sorry about the clunky graphics!)
Due to the dynamic type resolution of o:XML, functions can't be directly
mapped - things like function overloading wouldn't work. There still
needs to be a core engine to manage transformed code, something in the
form of node libraries to link to. But the whole transformation thing is
one of the key selling points of o:XML.
Regarding Java integration, have you seen the Java language extensions? ->
http://www.o-xml.org/objectbox/java.html
For using o:XML from inside Java apps it seems that BSF is a good way to
go, but I haven't really used it myself.
> When you make design changes or add new features, what is in your mind? Make
> it
> more object oriented or script like or in between?
The only non-OO features of o:XML are procedures, and functions that are
defined on their own (ie non-type functions). Also statements can be
"free-floating" in an XML document, which i guess is sort of script like.
I personally think that OO constructs should be a resource to developers,
a tool that is available when needed.
Encapsulation and modularisation allows applications to grow in a
controlled way, but i don't think they should be imposed as the one and
only programming method. Remember, there is no silver bullet!
The next couple of big features coming up are reflection and threads, both
will be done in a mostly OO way.
I've got a few ideas about how to do threads, but it might require a bit of
work. It should be really simple to use, along these lines:
<o:asynch>
<!-- runs in separate thread (grabbed from a pool) -->
</o:asynch>
the asynch block returns immediately with a Thread node, which can be
grabbed by wrapping it in an <o:variable>.
Also possible to declare asynch functions:
<o:function name="xx" access="asynch">
an asynch function call returns immediately, again with a Thread node.
the calling thread can continue whatever it was doing without waiting for
the function call to finish executing.
Thead.wait(), Tread.suspend(), Thread.interrupt() etc all work as expected.
Thread.result() waits for the thread to finish, and returns the result.
oh, and reflection, now that's going to be real nice... but more about
that later!
cheers,
/m
Martin Klang
http://www.o-xml.org - the object-oriented XML programming language
|
