On 1/25/13 12:44 AM, Andrea Pescetti wrote:
> Rob Weir wrote:
>> I also like the idea of marking a function as deprecated, maybe even
>> supporting the new and old together for a release, to give time for
>> transition.
> If at all feasible, I would be for this. Ideally, we should be able to
> install a legacy extension by: recognizing it's using legacy APIs or
> conventions; displaying a warning; running it anyway, trying to be as
> compatible as possible.

this would be indeed nice and if easy possible we would probably do
that. But the reality is that we don't have the resources to spent
enough time on this.

We have as deprecated marked API's and I am sure that people will still
use it. These API's are probably deprecated since > 3-4 versions and we
should be save to remove them. But I am sure people would complain about
it if there macro, solution won't run anymore.

We discussed incompatible changes probably 2 years ago and all people
participated in this discussion agreed on incompatible changes in a
major release. We agreed also that incompatible changes are allowed only
if a migration path is available and clearly documented.

For example merging interface XMyInterface, XMyInterface2, XMyInterface3
should be straight forward for Basic developers because the binding hide
the interface hierarchy anyway. For Java/C++ developers it means minor
code changes (removing the pseudo version number) and recompiling the code.

Other changes require potentially bigger changes but if they are well
documented it should be also possible with moderate effort.

It is really a tightrope walk to find the right balance but I believe
that we have to look forward and should improve things.

The API is of course not easy and far to complex and it is a shame that
we didn't put more effort in the past into better and well designed
API's. The overall idea of having one API for internal usage as well as
external (extensions, macros etc. from different languages) is of course
a good one. But is not complete and some things are still missing.

For some things it would be probably good to have some additional high
level API's with good defaults that cover 80% of all use cases (this is
for example the big plus of VBA).

A much better tooling like the NetBeans plugin that simplifies the
development a lot. Bernards XRay tool or the idea of the
InstanceInspector .... A more powerful Basic IDE or an
integrated/bundled power IDE for Python would be also nice. Some core
work and API's for such integration is available but the developers who
are interested to help here are missing.

Eclipse which is probably more popular as NetBeans lacks of support for
OO development at the moment. I see there good opportunities but we need
help to work on such things.

> Then of course I don't know how much of this is realistically
> feasible... but Hans is right, the ecosystem is extremely important and
> even unsupported extensions can have a high value for end users (while
> from a technical point of view it's hard to disagree with Juergen and
> Ariel).

The eco system is of course important but it is also important that we
work together. With a little more effort developers can help to improve
the user experience and can use version dependencies to ensure that
extensions work with the latest office. The auto update mechanism should
help to easy provide new tested versions after an office upgrade.

We have potentially detail problems here but this can and should be
fixed. I am nowadays a big friend of min/max dependencies because that
gave me the opportunity to satisfy my customers with always working

There is probably no 100% correct way but I am for innovation and making
things better over time.

The key element for me with all this changes is a clear and well
documented migration path.


> Regards,
>   Andrea.

Reply via email to