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 extensions. 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. Juergen > > Regards, > Andrea.
