You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Except for the reserved words, users are free to use whatever identifiers they wish for custom variables, types, and functions. The standard describes the variables, types, and functions provided in the standard environment. (We leverage the mechanisms of the protocol buffer package namespace to prevent collisions for message names.) User variables and functions will shadow these standard ones, so new additions to the standard won't change the meaning of user programs. However, it means that some users will not be able to access new functionality without potentially changing their user environment to rename things out of the way - which can be burdensome if they have a large library of expressions for that environment.
Proposed that the cel.* namespace be reserved for the standard CEL language. It is unlikely that any users are currently using this namespace, and those that are should not be surprised by this annexation. This will allow new entries to the language standard to be available to all users regardless of their environment.
Perhaps also add new entires to the unqualified namespace for more streamlined use when there is no collision.
Perhaps also copy all existing standard definitions into the cel.* namespace for uniformity, and to allow full use of unqualified names.
Perhaps use a modification of the container mechanism to implement the previous two properties.
The text was updated successfully, but these errors were encountered:
Except for the reserved words, users are free to use whatever identifiers they wish for custom variables, types, and functions. The standard describes the variables, types, and functions provided in the standard environment. (We leverage the mechanisms of the protocol buffer package namespace to prevent collisions for message names.) User variables and functions will shadow these standard ones, so new additions to the standard won't change the meaning of user programs. However, it means that some users will not be able to access new functionality without potentially changing their user environment to rename things out of the way - which can be burdensome if they have a large library of expressions for that environment.
Proposed that the
cel.*
namespace be reserved for the standard CEL language. It is unlikely that any users are currently using this namespace, and those that are should not be surprised by this annexation. This will allow new entries to the language standard to be available to all users regardless of their environment.Perhaps also add new entires to the unqualified namespace for more streamlined use when there is no collision.
Perhaps also copy all existing standard definitions into the
cel.*
namespace for uniformity, and to allow full use of unqualified names.Perhaps use a modification of the container mechanism to implement the previous two properties.
The text was updated successfully, but these errors were encountered: