[Qgis-developer] Expression engine functions and naming

[Martin Dobias]

Hi again

On Fri, Jun 20, 2014 at 11:19 AM, Nyall Dawson <nyall.dawson at gmail.com> 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