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
I would like to propose that the spec explicitly addresses implementation specific functions. Allowing a provision for functions specific to the implementation will free up those communities to expand features and functionality while not risking colliding with future additions to the spec.
I propose a prefix to non-spec functions. This will inform the end user that the function may change or be replaced in the future. Perhaps prefix these function names with an X, _, $, or #. Any custom functions provided by the library implementation or importing application will automatically be prefixed with this character.
Opening up the spec like this will allow innovation and test beds to be created. Non-spec functions that gain popularity can then be evaluated for inclusion into the spec. This will also alleviate any confusion when a custom function is encountered in the wild as it will be made clear that it is not supported by other implementations.
The text was updated successfully, but these errors were encountered:
I would like to propose that the spec explicitly addresses implementation specific functions. Allowing a provision for functions specific to the implementation will free up those communities to expand features and functionality while not risking colliding with future additions to the spec.
I propose a prefix to non-spec functions. This will inform the end user that the function may change or be replaced in the future. Perhaps prefix these function names with an
X
,_
,$
, or#
. Any custom functions provided by the library implementation or importing application will automatically be prefixed with this character.Opening up the spec like this will allow innovation and test beds to be created. Non-spec functions that gain popularity can then be evaluated for inclusion into the spec. This will also alleviate any confusion when a custom function is encountered in the wild as it will be made clear that it is not supported by other implementations.
The text was updated successfully, but these errors were encountered: