Eskil Abrahamsen Blomfeldt wrote: > It is unfortunately a general binary compatibility problem in Java > that adding new methods to existing classes can have effects on > preexisting subclasses. > > The options we have are: > 1. Do not add public or protected methods to existing classes in any > update (which is our policy for patch releases.) > 2. Make all new methods in existing classes virtual, which not only > pollutes the API and makes it difficult to use, but also causes > methods to called on unexpected times and will cause erratic behavior > which is both difficult to debug and has potentially dangerous effects. > 3. Make all new methods in existing classes final, which is what we > are doing in both Qt for C++ and Qt Jambi, and which will cause a > static error to occur when the code seizes to be compatible. > > Choosing the third option will give you an easily debuggable exception > in the Java verifier on startup of the application if there should be > any naming collisions in your code, and will keep the API clean. The > naming collisions cannot be avoided in general, unless we choose not > to update existing classes, as in option 1. This is what our patch > releases are for. The minor releases (like 4.4.0) are for introducing > new API. > > The only thing we can do in this particular case is to change the name > of setProperty() to something else. Is this the only method in > question? I will register a suggestion for doing this, but I cannot > guarantee that it will be accepted, as we are very late in the 4.4 .0 > development cycle, and we also need to consider the readability of our > own API. If the suggestion should not get accepted, the only solutions > I can see is to continue using the Qt Jambi 4.3-series or to manually > patch your local copy Qt Jambi to support the extensions you need, > unfortunately. > > Thank you for the report! > > -- Eskil >
Hi Eskil Thanks for the reply. May I humbly suggest that setProperty be changed to setQProperty as this would seem to be consistent with other naming in Qt. I'm not sure whether this is the only method in question - I am working with Qt exclusively through Groovy and as I said this is kind of a show stopper - I cannot get any further. I am in the planning stages of moving a rather large project to a more modern language. I thought that groovy + Qt was the answer - but this problem puts a damper on things. Groovy's closures and lack of scaffolding code and dynamic nature are what make it attractive to me - Qt's slots and signals appeal for the sames reasons. Basically I feel that both technologies allow me to concentrate on the forest rather than the trees. (For non native English speakers I'll explain that last reference - there is an expression "I can't see the forest for the trees" which basically indicates that the details are getting in the way of seeing the big picture.) It may be that Qt will find a wider audience with Groovy developers than Java developers. There is a small problem with adding signals to qt objects in groovy - but I have a work around for that. In fact I have several examples of interesting groovy/jambi code. If there is a good chance that I can affect the decision regarding the name of the setProperty method I can spend some time and clean it up a bit and then send it to you. Todd. _______________________________________________ Qt-jambi-interest mailing list [email protected] http://lists.trolltech.com/mailman/listinfo/qt-jambi-interest
