Hi Laurent,
I try to respond inline to your points
Laurent Godard wrote:
Hi Noel
Thanks for your proposal and your presentation
Thnks,
I'm aware that VBA macros are a problem on a migration and something has
to be done. So you're proposal is welcomed
Nevertheless, I'm afraid that using VBA paradigm inside OOo will more
hurt than solve the problem. VBA has 2 parts : the language and the objects
I'm not talking about the syntax here. Some compatibility efforts have
been done in this directon and can be improved.
One of the goals is to improve/add to those existing compatibility efforts.
The problem, imho, is on the API level
Giving VBA support as you propose is implementing a new API for objects.
You will then have two ways for defining objects : the OOo API one, The
MS VBA one.
It will be more difficult to understand things as these two
objects, will have difference : a VBA cell is different tha an OOo one.
A VBA-like API is necessary for allowing VBA macros to run, sure a
secondary affect is that the interopability API will also now become
available if someone wishes to use it. I don't see this as a problem.
The OOo API is although very powerful, it is also very find grained ( &
some people would say it's too fine grained & developer-centric rather
than scripter-centric ) On the other hand an api that provides
interoperability capabilities is a higher level abstraction of the OOo
API. I don't see the 2 apis as competing or mutually exclusive rather
that they compliment each other, they are different tools for doing
different tasks. And of course the interop api is built on top of the
existing API
How does this interact ? Is a VBA macro allowed to mix both API ? Is
python script allowed to use VBA objects and OOo objects ?
The API is an UNO api, therefore can be leveraged by any scripting
language, as for mixing the API again I don't see any barrier there.
Are VBA macros only restricted to MS File format (i see no technical
reasons for this)
Not sure what you mean here, a new API ( or set of APIs) will exist, its
possible that access to that api could be limited ( e.g. to an xls file
only ) but I don't think that is a good idea, imo freedom of choice is
better.
For me, at the end, it will be the end of any scripting language except
VBA one. Forget OOoBasic, python, Beanshell or javascript.
Wow, I don't know how you could come up with such a statement. There is
no new scripting language being implemeneted just:
* an API implementation ( wrapping the existing API )
* some magic in OOobasic that does some syntatic sugar coating that
helps VBA code run within easier in OOo.
I don't see how that can affect someones choice of scripting language.
If someone wants to use java or python or whatever, normally they make
that choice based on what scripting language they know best, what the
language offers them etc. Each scripting language has different
benifits/strenghts but each scripting language mentioned has access to
all of the uno API functionality including the new interoperability stuff.
VBA is widely
spread due to MS file format domination. Many people do know how to
create VBA macros and then it will end with a big proportion of this
language.
Thats just reality, if you want people (especially organisations) to
migrate to OOo, you have to make it easy for them especially in terms of
collateral that they have in terms of legacy documents etc. Facilitating
that is a primary goal.
A lot of documentation exists and we will be asked more and
more to implement VBA subtilities
We don't know what will happen so who can say what kind of requests will
be made. But is this any different to any other aspect part of OOo?
Where requests for new features of enhancements take place, they have to
be dealt with individually and evaluated in terms of importance,
usefulness etc.
But, VBA is not free ! OOo Project has no influence on its specification
and it can be changed without any warning (look at the difference
between MsOffice versions)
Moreover, what about legal issues ? Are we sure there are any patent on
this ? Are we allowed to implement an interpreter ?
Well I'm not a lawyer so I can't really comment other imo than it seems
to me that this area is just as grey ( if it is grey ) as other parts of
OOo where there are "striking" similarities to "other" office products
in terms of ui, usage patterns,scripting language and objects. And
still, just to be clear, there is no interpreter implementation other
than the existing OOobasic.
Noel, I'm really enthousiastic by you project in a technical point of view.
But, i have to say -1 for the resons i gave, unless we build some
policies like (only proposal, ideas not worked)
- restrict vba to ms office file format (not opendocument or addons)
nah, can't see that's benificial, free software, freedom of choice...
- translate the VBA source code to OOo API to only have to deal with one
model
So -1 for me
But totally open to discussion
Well hopefully some of the above eases your concerns ( maybe not ), in
anycase I'm just as open to discussion on same
Regards
Laurent
Noel
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
