[Qgis-developer] Expression engine functions and naming

[Andreas Neumann]

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
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>