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
For an API entry point called Foo, Silverchain currently creates state interfaces called FooN and classes called FooNImpl (N = 0, 1, ...).
As discussed in chat, I believe that having numbers in a class name is unusual enough that it should help API users remember that these intermediate types are somewhat special, i.e. that keeping references to them in variables threatens the forward compatibility of their own code.
However, I now think that a fluent API could emphasize the fragility of its intermediate type names even more by incorporating non-latin Unicode characters. As Java identifiers can include any Unicode character that is a letter, digit or currency symbol in any language, one can certainly find a character that signals "this is unusual". For example, my current favorite is ⴵ because it is as large as a capital letter (and thus unlikely to be overlooked) and resembles an hourglass (fitting the "call in progress" nature of a method chain).
That said, Silverchain should not make that choice for API developers, but default to the safe, (hopefully) non-controversial FooN style. I propose adding an optional configuration setting called stateNameFormat which is a MessageFormat pattern:
stateNameTemplate
Interface Name
Class Name
{0}{1} (default setting)
Foo7
Foo7Impl
{0}ⴵ{1}
Fooⴵ7
Fooⴵ7Impl
{0}{1,number,0000}
Foo0007
Foo0007Impl
State{1}Of{0}
State7OfFoo
State7OfFooImpl
Silverchain would not have to validate anything here; if the resulting name is not a valid Java identifier or results in non-unique type names, the Java compiler will complain anyway:
stateNameTemplate
Interface Name
Class Name
Remark
Fun
Fun
FunImpl
Non-unique
{0}
Foo
FooImpl
Non-unique
{1}
7
7Impl
Invalid identifier: starts with a digit
{0}⛔{1}
Foo⛔7
Foo⛔7Impl
Invalid identifier: '⛔' is not a letter/digit/currency
The text was updated successfully, but these errors were encountered:
For an API entry point called
Foo
, Silverchain currently creates state interfaces calledFooN
and classes calledFooNImpl
(N = 0, 1, ...).As discussed in chat, I believe that having numbers in a class name is unusual enough that it should help API users remember that these intermediate types are somewhat special, i.e. that keeping references to them in variables threatens the forward compatibility of their own code.
However, I now think that a fluent API could emphasize the fragility of its intermediate type names even more by incorporating non-latin Unicode characters. As Java identifiers can include any Unicode character that is a letter, digit or currency symbol in any language, one can certainly find a character that signals "this is unusual". For example, my current favorite is
ⴵ
because it is as large as a capital letter (and thus unlikely to be overlooked) and resembles an hourglass (fitting the "call in progress" nature of a method chain).That said, Silverchain should not make that choice for API developers, but default to the safe, (hopefully) non-controversial
FooN
style. I propose adding an optional configuration setting calledstateNameFormat
which is a MessageFormat pattern:{0}{1}
(default setting)Foo7
Foo7Impl
{0}ⴵ{1}
Fooⴵ7
Fooⴵ7Impl
{0}{1,number,0000}
Foo0007
Foo0007Impl
State{1}Of{0}
State7OfFoo
State7OfFooImpl
Silverchain would not have to validate anything here; if the resulting name is not a valid Java identifier or results in non-unique type names, the Java compiler will complain anyway:
Fun
Fun
FunImpl
{0}
Foo
FooImpl
{1}
7
7Impl
{0}⛔{1}
Foo⛔7
Foo⛔7Impl
The text was updated successfully, but these errors were encountered: