Front page | perl.perl5.porters |
Postings from March 2022
Okay, I have even BETTER name proposals: - is_classified_as_number() - is_classified_as_string() - is_classified_as_boolean() See also https://docs.raku.org/routine/classify for precedent. The POINT here, as I see it, is we want to be able to take any given Perl value and deterministically classify it into EXACTLY ONE mutually exclusive type. This is all about, we have a value, sort it between various choices where it fits best. It doesn't exactly matter how we got to that point as long as a clear decision is made. This tends to correlate with decisions made on creation or use but using "classify" avoids implying things beyond the use case of sorting. As for "canon", I agree it is much less linguistically clear as to why I chose that, but what I was going for was as in "canonical works" or "authorized; recognized; accepted", the idea that we made an official position on what criteria of a Perl value sorts it as a number versus a string etc. But even if I still think "canon" makes sense, I put forth that "classify" gets the point across much better. I should say however, that my wider proposal is actually more of a hierarchy than a strict mutually exclusive decision. Loosely speaking, this for example: - is_classified_as_undef() - is_classified_as_boolean() - is_classified_as_number() - is_classified_as_integer() - is_classified_as_float() or is_classified_as_fraction() - is_classified_as_string() - is_classified_as_text() - is_classified_as_blob() - is_classified_as_array() - is_classified_as_hash() - is_classified_as_object() in the Corinna sense So all leaves of the hierarchy are mutually exclusive and every Perl value is a member of exactly 1 leaf, but when leaves have parent nodes, then when a value is a member of a child it is also a member of a parent. Critically this also means we can and should be able to have also: - most_specific_classified_type_of() ... or similarly named which results in a STRING like "boolean"/"integer"/"float"/etc that one can then use in a given-when expression etc. Now I realize the subtypes of "string" here may be more complicated since in practice the same representations may overlap, so resolving that this time could be skipped if there isn't a good solution at this time, while still keeping the rest of what I said, and in fact the hierarchy approach intentionally gives us room to grow and evolve. The integer vs float thing we should be able to do right away though. Ovid and others, what do you think of that? -- Darren Duncan On 2022-03-14 3:53 a.m., Ovid via perl5-porters wrote: > On Monday, 14 March 2022, 06:37:26 CET, Darren Duncan <darren@darrenduncan.net> wrote: > >> I made good name proposals already: >> >> - is_canonically_a_number() >> - is_canonically_a_string() >> - is_canonically_a_boolean() > > Naming is hard. Very hard. It's even harder when many people are non-native English speakers. I'm a native English speaker and a writer and it wasn't clear to me that "canonically" is appropriate here. I hit dictionary.com (https://www.dictionary.com/browse/canonically) and not a single definition appears to fit the meaning of this as I understand it. You could check other dictionaries, such as Merriam-Webster, Collins, etc., and again, canonically doesn't quite seem to fit (Collins seem the closest to what you're saying https://www.collinsdictionary.com/dictionary/english/canonical) > > The most accurate description I can think of is something like: > > was_initialized_as_number() > > But we don't do past-tense, so perhaps the slightly awkward: > > is_initialized_as_number() > > I *think* this is: > > * Accurate > * Non-native speakers will already know "Initialized" > * Long and cumbersome enough to be annoying :( > > I'd welcome something better, but I can't think of anything. (I also thought "is_declared_as_number()", but that feels subtly wrong to me) > > Best, > OvidThread Previous | Thread Next