+1 from me too on camel case and the aliases for compatibility On Thu, 10 Nov 2022 at 7:47, Miklosovic, Stefan < stefan.mikloso...@netapp.com> wrote:
> Adding snake case aliases for existing functions which are in camel case > for compatibility and stick to snake case from now on seems to be like a > good idea. > > ________________________________________ > From: Andrés de la Peña <adelap...@apache.org> > Sent: Thursday, November 10, 2022 13:20 > To: dev@cassandra.apache.org > Subject: Naming conventions for CQL native functions > > NetApp Security WARNING: This is an external email. Do not click links or > open attachments unless you recognize the sender and know the content is > safe. > > > > 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? >
