Hi again On Fri, Jun 20, 2014 at 11:19 AM, Nyall Dawson <[email protected]> wrote: > Hi all, > > I thought I'd raise an issue which has been on my mind a bit lately, > and I'm not sure how to proceed with fixing it. At the moment there's > a huge lack of consistency in function names in the QGIS expression > engine. Here's some examples: > > - Some functions use the naming convention of seperating lowercase > words with underscores, for example "format_number", "format_date", > "color_rgb" > - Others use all lowercase, no underscore, eg "tostring", "wordwrap" > - Still others use camel case, eg "geomFromWKT", "symDifference" > > Basically, we've got a mix of every naming convention possible. I > think there's an urgent need for us to choose a convention and ensure > that all newly introduced functions adhere to this.
The function names are case insensitive, so the problem boils down to with / without underscore. It seems that even in SQL function naming there is not really a common rule which is the preferred option... > The follow up question is whether or not we can clean up this mess. > Can we rename functions in a way that doesn't negatively impact users? > Possibly we could have aliases for functions which evaluate ok so that > older projects can still work, but which aren't shown the the user in > the dialog. Yeah, we could do that. Later, in QGIS 3 we may remove them completely and provide helpers for loading of older projects to transform the expressions to newer syntax. > There's also some function names & formats which really bug me, specifically: > - "$feature", "$numfeatures". Ideally these should be named something > more appropriate like "$atlas_feature_num" and "$atlas_feature_count", > since they directly relate to atlas variables. From their names it > seems more logical that these would return the current feature and > number of features in the current layer. True. To follow up my previous mail, I would like even more to have object $atlas with nested values, so we would use dot notation e.g. $atlas.feature_count And maybe we should just do more planning when adding new stuff to expressions. Maybe some small RFCs...? > - I made a dumb decision when I created the "clamp" function and put > the parameters in the "minimum,input,maximum" order. In retrospect > these should be "input,minimum,maximum" Actually I like the former syntax - although it seems that most of APIs use the latter... > I'm guessing there's nothing we can do to retrospectively fix these > inconsistencies now? Not much I guess. This is very similar to API problems, with the difference that expressions affect not only developers, but also users. Regads Martin _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
