Hi, Yes. When I initially saw $feature and $numfeatures I thought - oh cool - I can have access to the feature-record - although - as you said it wasn't clear which feature this would be refering to. This naming is really sub-optimal and hopefully we can still correct it.
When was this introduced? In 2.4? If yes, there can hardly be any content using this and I would propose to correct this today before we ship. As to the other cleanup: what you propose: adding aliases in 2.6 and then deprecate the old inconsistent function names in a later version sound like a plan to me. Andreas Am 20.06.2014 04:19, schrieb Nyall Dawson: > 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 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. > > 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. > - 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" > > I'm guessing there's nothing we can do to retrospectively fix these > inconsistencies now? > > Cheers, > Nyall > _______________________________________________ > Qgis-developer mailing list > [email protected] > http://lists.osgeo.org/mailman/listinfo/qgis-developer > _______________________________________________ Qgis-developer mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/qgis-developer
