From: Matthew G. <mat...@gm...> - 2012-02-20 17:45:29
|
Changes to StelModule public slot names are not insulated from the scripting language. Public slots of classes whose instantiated objects are made available to the script engine make up a large part of the scripting API. This is how QTs scripting engine works, and in my view it's a perfectly good way to go about things. This difference between the "core" scripting object and the various StelModule objects is directly resultant from how Stellarium's code is [very deliberately] structured - that the core classes provide a low-level API from which the various StelModule are implemented, with the StelModule's providing a fairly fixed interface to the user. As you mentioned in IRC, using Q_PROPERTY should make things more robust, and other features easier to implement, and I think this is good idea, and work which should be continued. I also agree that API changes are inevitable, and sometimes a good thing. However, API churn is a terrible thing unless there is a compelling reason to do it. Somewhat improved function names has to be measured against this. Probably there are as many opinions about the relative weights as there are developers. I suppose I err on the side on not breaking user scripts in the wild. So what now? In the StelModules which have had the Q_PROPERTY treatment so far, I will revert the name changes (leaving the Q_PROPERTY code). Let's change the rest of the StelModules to use Q_PROPERTY, leaving the names alone for now. Once this is done, it's not such a big task to do an API name change later. M On 20 February 2012 05:59, Reaves, Timothy <tr...@si...> wrote: > I think the changes do add value. isXXXDisplayed will let you know if XXX > is displayed. getFlagXXX -especially getFlagNames - tells you nothing. As > far as the scripting API goes, the uses should have been updated too. But > the scripting API should have insulated any scripts from the names of > methods, regardless of if they are in the 'core' or not. That they do not > shows a very poor implementation decision on someones part. It leads to > fragile scripts. > > API's change. They improve; if not, they end up like Java. Consistency for > the sake of consistency is not a good idea, as much as people like to banter > it about. getFlagNames is bad. isNamesDisplayed is better. That this > change will cause some scripts to need to be updated may be unfortunate, but > that's progress. > > I do not think the names should be changed back. Providing a release > document with the name changes is reasonable. Users would just need to look > at the document, and update their scripts accordingly. > > As an aside, Stellarium does not - and probably never will - use QT. QT is > a technology used for playing audio & video. > > On Sun, Feb 19, 2012 at 7:50 PM, Matthew Gates <mat...@gm...> wrote: >> >> Recent changes to use the QT properties system have included the >> renaming of many core class member functions. In the case of public >> slots, this directly changes the scripting API. I also don't think >> the replacements offer any real improvement over the previous names >> (e.g. getFlagNames vs. isNamesDisplayed). >> >> Please change the names back. >> >> M >> >> >> ------------------------------------------------------------------------------ >> Try before you buy = See our experts in action! >> The most comprehensive online learning library for Microsoft developers >> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, >> Metro Style Apps, more. Free future releases when you subscribe now! >> http://p.sf.net/sfu/learndevnow-dev2 >> _______________________________________________ >> Stellarium-pubdevel mailing list >> Ste...@li... >> https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > > > > ------------------------------------------------------------------------------ > Try before you buy = See our experts in action! > The most comprehensive online learning library for Microsoft developers > is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, > Metro Style Apps, more. Free future releases when you subscribe now! > http://p.sf.net/sfu/learndevnow-dev2 > _______________________________________________ > Stellarium-pubdevel mailing list > Ste...@li... > https://lists.sourceforge.net/lists/listinfo/stellarium-pubdevel > |