For logging purposes status constants (done, cont, fail) are postfixed with a () which may optionally include logging information:
return done(log && "All caught up");
Without disregarding #28, test-oriented workflows are less dependent on logging and, overall, an option to use plain status constants would be welcome.
Still unclear whether both plain and annotated status constants may coexist in the same class (it only looks impossible). That isn't really a problem though.
Also, marginal performance gains with raw constants.
Plain and bracing constants in the same context is possible. Performance is roughly the same as before. Underlying pattern is not simple, so this should be done in a branch first to ensure no typing related conflicts.
A separate namespace may be provided for 'raw' status values. They are twice as fast, which may seem a lot, but probably isn't (overall impact in practical applications, likely very small).
Reasonably, splitting the namespace should be the first option.
For logging purposes status constants (done, cont, fail) are postfixed with a
()
which may optionally include logging information:Without disregarding #28, test-oriented workflows are less dependent on logging and, overall, an option to use plain status constants would be welcome.
Still unclear whether both plain and annotated status constants may coexist in the same class (it only looks impossible). That isn't really a problem though.
Also, marginal performance gains with raw constants.