> > IMO camel case would make sense because it plays well with CQL's case > insensitivity, it makes long names easier to read and it's consistent with > the names used for most other things.
I meant that we should use snake case, as in "collection_max" and the other example I give, but I wrongly wrote camel case instead. I'm sorry for the confusion. I understand that Ekaterina and Brandon meant the same, adopting snake_case as the convention and use camelCase aliases for compatibility. On Thu, 10 Nov 2022 at 13:26, Brandon Williams <dri...@gmail.com> wrote: > +1 on camel case and aliases for compatibility. > > On Thu, Nov 10, 2022, 6:21 AM Andrés de la Peña <adelap...@apache.org> > wrote: > >> It seems we don't have a clear convention on how to name CQL native >> functions. >> >> Most native functions are named all lower case, without underscore nor >> hyphen to separate words. That's the case, for example, of "intasblob" or >> "blobasint". >> >> We also have some functions using camel case, as in "castAsInt" or >> "castAsTimestamp". Note that the came cased names require quoting due to >> CQL's case insensitivity. >> >> Differently to CQL native functions, system keyspaces, tables and columns >> consistently use snake case. For example, we have "system_schema", >> "dropped_columns", "default_time_to_live". >> >> I think it would be good to adopt a convention on how to name CQL native >> functions, at least the new ones. IMO camel case would make sense because >> it plays well with CQL's case insensitivity, it makes long names easier to >> read and it's consistent with the names used for most other things. >> >> For example, in CASSANDRA-17811 I'm working on a set of functions to do >> within-collection operations, which would be named "map_keys", >> "map_values", "collection_min", "collection_max", "collection_sum", >> "collection_count", etc. Also, CEP-20 will add a set of functions that >> would be named "mask_null", "mask_default", "mask_replace", "mask_inner", >> "mask_outer", "mask_hash", etc. >> >> As for the already existing functions, we could either let them be or add >> snake case aliases for them, so for example we'd have both "castAsInt" and >> "cast_as_int", at least for a time. >> >> What do you think? >> >
