Poll: Casing of check names

[Ovid]

There are several different ways the case of the data checks could be applied. We have built-in data checks and user-defined checks.

Given that all of the built-in checks are conceptually a single work (with the possible exception of NONREF), the casing on them isn't particularly impacted by CamelCase.

Built-In Style	Built-In Example	User-Defined Example	User-defined note
SHOUTY	HASH	PositiveInt	User-defined requires one lower-case
Titlecased	Hash	positiveInt	User-defined requires leading lower
All lower	hash	PositiveInt	User-defined requires leading upper

[Ovid]

SHOUTY checks

Per Damian regarding the "Shouty" checks:

In other words, the choice of uppercase names for built-ins is a deliberate syntactic “disaffordance”: a carefully selected psychological disincentive to discourage the use these low-level and uninformative checks directly, and a subtle encouragement to compose them into well-named, self-explanatory, and vastly more maintainable user-defined checks instead.

There has been some disagreement over SHOUTY checks (some of this in private feedback on an original private discussion). Further, in reading through code examples in other languages, there are plenty of times where native checks seem perfectly fine. My final concern was that I knew someone would release a module providing different names for native checks:

check int  :isa(INT);
check hash :isa(HASH);
# and so on

Given the user can (and will) trivially subvert the check names, it seems to make sense to go for names that are the least contentious.

That being said, the container checks (such as HASH) already make well to the output of ref $value.

Titlecased

Having built-in checks be title-cased (Int, Hash, Glob) seems a nice compromise, though that means user-defined checks must start with a lower-case letter (or be SHOUTY!). That seemed kinda ugly to me. However, this might lead us to eventually be able to do this (as would SHOUTY checks):

my Int   $foo = 0;
my int64 $foo = 0; # using native types for raw performance

I'm not sure about the latter comment, but it seems like it could be a huge win in the long term. That being said, if possible, that's post-MVP and not something to bikeshed now unless it impacts current design.

Lower-case

I am concerned about throwing up impediments to people using checks in the first place. Further, the more our check system will feel familiar to programmers from other languages. Thus, lower-case built-in checks would (sort of) map to what languages such as Java does. For example, with Java, you have primitive data types (int, char, etc.) and non-primitive types such (String, arrays (float[] grades) and classes (Dog spot = new Dog()).

In fact, for many common languages, native types are all lower-case.

Language	Declaration
Go	var age int
Java/C/C++	int age
TypeScript	let age: number = 42;

So encouraging a familiar style and not discouraging checks via "SHOUTY" could be valuable.

[Ovid]

@druud @happy-barney @perigrin @rabbiveesh @rwp0 @SysPete @tobyink @demerphq

A poll! Hopefully this will make some decisions clearer.

[happy-barney]

user-defined checks - leave it up to user, just prohibit overriding primitives
primitives:

• I prefer title case, with all of them defined in package CORE (so one can use fully qualified eg CORE::Int)
• it's consistent with currently used approach (Moose, Type::Tiny)
• moreover, I prefer title snake case, eg Positive_Int - reason is as always, space (whitespace or underscore) provides optical anchor

why not shouty - one identified is acceptable but when used in expressions (esp with those unfriendly omitting whitespaces, eg INT|STR|NUM|UNDEF
why not lowercase: single reason - existence of int

[Ovid]

I think there's already been general agreement that data checks will not share an existing namespace.

The Moo/se, Type::Tiny considerations are important. If someone mixes data checks with Type::Tiny, there could be clashes.

[Ovid]

As for the existence of int, we're already able to define methods which could "shadow" builtins: $foo->dump. Since we can distinguish them syntactically and since data checks won't share the same namespace, I think we can live with this small nit.

[happy-barney]

difference is that methods are used with dereference syntax. here it will be standalone identifier. but that's only my point of view and it has nothing to do with separated namespaces. More specifically: title is preferred, small with postfix is almost at same level.

[Ovid]

If anyone else can comment/vote, I'd appreciate it 😃

[happy-barney]

(over) thinking:
I didn't notice that earlier, but regarding single word expectation: core should contain widely use checks - and imho Positive_Number, Negative_Number (Num variants) are widely used as well, enough to advocates them in core. Hmm, same as various date/time values :-(

[Ovid]

The numeric checks, maybe non-empty string, but that scope creep is going to make this even harder to get done. I'm trying to fight burn out here and every bit more we push in means it's less likely to get done.

Also, there's no way we can possibly handle the ridiculously wide variants of dates, times, date times, time zones, local formatting, epoch times, US vs ISO, and so on.

[happy-barney]

Agree ... that's why I started roadmap discussion - let's put common constrained primitives (even sub-language for constraining, like min length / max length, ...) into milestone after mvp, and date/time even later.

I think first part should be generic support for separated symbol spaces in core - that behaviour is necessary for this and has greater usage than this as well.

[demerphq]

I think i lean towards SHOUTY, TitleCased, lower_case in that order. Damian Conways argument about disaffordance makes sense to me.

[duncand]

I feel that for type or check names the best practice is to use the same naming pattern for system-defined and user-defined ones. What is good for one is good for the other. For all of the above I specifically recommend Title_Snake_Case. But also there should be no restrictions on user-defined type name styles, users should be able to use any valid Perl identifier syntax for their check names, including ones that use the same style as system-defined ones. Distinguishing system-defined ones should be done in some other way, like how we have builtin:: now, and CORE:: historically, as a disambiguator where needed.

[Ovid]

The reason for the different naming conventions stems from the Principle of Parsimony: not backing ourselves into a corner.

If user-defined and built-in types allow the same naming convention, we can't easily add more built-in types because the common types we might like to add are probably added by others and we will have name conflicts. If we have to add special prefixes later for disambiguation, that makes declarations more complex. We're hoping for a simple solution. That being said, I understand where you're coming from and it's worth thinking about.

[happy-barney]

we can ... in case of conflict user will be required to use fully qualified name

[tobyink]

I do think that user-defined checks should technically be able to use the same naming convention as built-in ones. It should just be strongly discouraged.

Why? Say, for example, data checks are introduced in Perl 7.0. Then in Perl 7.2 a new built-in data check DUALVAR is introduced. If I want to write code dealing with dualvars that runs on Perl 7.0, I should be able to do something like this to "backfill" the new data check to Perl 7.0.

if ( not eval 'my $dummy :of(DUALVAR); 1' ) {
  check DUALVAR ( $value ) {
    return Scalar::Util::is_dualvar( $value );
  }
}

Analogously, I can already do this to make CORE::fc available on Perl versions older than 5.16:

if ( not eval 'CORE::fc(q//); 1' ) {
  *CORE::fc = sub { lc( @_ ? @_ : $_ ) };
}

[druud]

Where 'technically' could mean that it needs a lexical <no strict "CHECKNAME";>, right?