Marco Fioretti wrote:
> Eh eh... This is the same simplification as OpenDocument = OO.o.
> It would be more exact to say that the *interpreter* of a macro
> must be written for the application that calls it (OO.o or whatever)
> and today the only macros found in pre-OpenDocument files (.sxw, .sxc)
> are written in a language that was designed only for *StarOffice*,
> not for its file *format*. See my other reply.
No, an interpreter will never be created for a format or even a
particular API, theoretically it can work with any API you provide to it.
I'm not sure if you understand the nature of a programming language for
an application. The interpreter is only a very small part of it, you
also need an inspection component and a language agnostic component
technology that mediates between objects. Additionally you need an API
that the inspection component can "read", but this API basically is
exchangeable.
In OOo the basic interpreter takes a given object that is based on the
UNO component technology, uses the so called "introspection" service to
find the methods and properties it has and dynamically "learns" them. In
the same way VBA takes objects based on the COM component technology and
inspects them.
All the found methods and properties can be used as object members in
your macro and make them look as if they are part of the language. This
way the macro "language" evolves automatically by adding new objects to
your application or extending the function or property set of existing
ones *without writing any line of code in your interpreter*.
As an example, you have only one VBA interpreter, but it is able to
execute macros for Calc as well as for Word, but you can also
instantiate other COM objects (even OOo on Windows!) and directly use
their COM based API in your VBA macro. The OOo Basic interpreter offers
the same flexibility with all UNO based objects. As an example, adding
the "Base" component in OOo2.0 gave you many grub for writing macros,
but not a single line in OOo Basic had to be changed for this.
In an extrem manifestation of this flexibility you can replace the
current OOo API by something completely different and you can work with
this new API without any change in your interpreter as long as you don't
replace the introspection component and its API and you use the same
component technology ("Middleware").
Of course an extreme API exchange like this is neither likely (because
it's too much work) nor possible (because it's forbidden by our
self-constraints concerning API compatibility), but as a thought
experiment it can show you how things work.
So creating a "compatible" interpreter for lets say KOffice will be only
the very first step to macro interoperability. By using Python (as you
correctly stated) you could even save this first step if you provided a
binding from Python to your component technology (like OOo has in
PyUNO). And this component technology is the key to everything.
If you want to be future-proof and keep it open for additional macro
languages in the future, your component technology should be language
agnostic by supporting the "language binding" concept (as COM and UNO
do), but at least it must be usable from your API implementation
language (like C++ in KOffice or OOo) and your scripting language.
A quick look to KDE.org it looks as KOffice has something like that, but
somebody in the know should confirm. Of course this is only for KDE,
Gnome has another component technology. I'm not an expert for this.
If this was all in place, *then* you could start defining and
standardizing an API and then implement it using the component
technology. This implementation can "wrap" the current objects of the
applications or in future times even replace them or at least make up
the new parts.
Best regards,
Mathias
--
Mathias Bauer - OpenOffice.org Application Framework Project Lead
Please reply to the list only, [EMAIL PROTECTED] is a spam sink.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
