MOP ^add_method could be renamed as ^add-method

[tisonkun]

Otherwise we might arrive where PHP is, mixing lots of name conventions.

So far we have named Type in UpperCamelCase, some of methods/varibles in kebab-case(is-prime), some of thoes in snake_case(has_accessor, get_value, set_value), some of those in lowercase(deepmap, roundrobin) and some(I cannot sort them neatly) in UPPERCASE. It might be helpful we keep consistency.

BTW, is there a report about rakudo name conventions? should we attempt to decide one?

[AlexDaniel]

It's not just add_method, I recall stumbling upon something else that wasn't low-level but had _ in it. Maybe we should generate a list of all things with underscores and take a look at things again.

[lizmat]

I think the last time I brought this up, jnthn felt it would be too disrupting. FWIW, I feel consistency is a bit more important, so I would be in favour of looking at this more deeply. Having said that, there may be other, more important things to look at as well :-)

…

On 2 Dec 2017, at 12:41, Aleks-Daniel Jakimenko-Aleksejev ***@***.***> wrote: It's not just add_method, I recall stumbling upon something else that wasn't low-level but had _ in it. Maybe we should generate a list of all things with underscores and take a look at things again. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[tisonkun]

yes, implement features, fix bugs and improve performance are important, while consistency is for long term development.

we can at first list/sort our names, so that the next time we reach here, we don't have to start from scratch

[tisonkun]

Types(classes and roles) are named in UpperCamelCase, which we just keep it.

PHASERs are all in UPPERCASE.

$=pod vs. $*VM, $*IN, $?FILE in built-in names

^add_method in snake_case, all(?) MOP

is-prime vs. deepmap vs. STORE

and so on

[jnthn]

This topic has already been discussed to death. Despite that, there are still a small number of cases in CORE.setting where we missed the _ to - transition, including in Thread where app_lifetime was missed out; see here. That one likely makes sense to do something about, as it stands out in that class which otherwise uses -, but it would need some care: we still must accept both names in the constructor and as a method call, and eventually mark the _ form deprecated after a a year or two. We can probably consider it unlikely anyone overrode that method in a subclass, since that would greatly complicate matters. Speaking of subclassing complications...

We settled long ago on MOP methods and other parts of the compiler's internals sticking with _. These would be very difficult to rename now, not just because their usage extends all the way down into the VM in some cases, but because the most typical way to write MOP extensions is to override methods, and these overrides typically will do callsame. So it isn't just a case of "let existing callers migrate to the new name and forward the old name". It's also an inheritance and composition interface (the latter meaning that we also expect two conflicting add_method implementations composed into a meta-object to conflict at role composition time; how will that happen if they were add_method and add-method?). Even if I thought a transition to - was a good idea in the MOP, I don't see an obvious good way to do it (without breaking a lot of stuff, which is not an option).

It's not just add_method, I recall stumbling upon something else that wasn't low-level

I invite anyone who feels add_method isn't a low-level mechanism to write out the rules one should know in order to use it successfully. :-) (Hint: there's at least 3 distinct scenarios to consider, and they each need different treatment.) I think much use of add_method today is either because:

1. For some reason, augment wasn't used, even though it would have been the right tool for the job
2. We don't have macros yet, and so add_method is the best thing people have

I'd rather we spend our efforts on those higher-level mechanisms, such that the need to use add_method - other than overriding it when writing a MOP module - will go away for most use cases anyway.

PHASERs are all in UPPERCASE.

is-prime vs. deepmap vs. STORE

Actually STORE and the phasers, along with AT-POS, BUILD, etc. are all following a single naming rule: things that the runtime calls for you at a time of its choosing get uppercased names. One never really calls STORE directly; they use the = operator, which calls STORE.

is there a report about rakudo name conventions? should we attempt to decide one?

Yes, please let's document the conventions that have been settled on over the years. Here's an initial suggestion, to expand on and flesh out:

• Subs and methods from the built-ins library (CORE.setting) try to have single-word names when a good one could be found. In cases where there are two or more words making up a name, they are separated by a -.
• Compounds are treated as a single word, thus substr, subbuf, and deepmap (just like we write "starfish", not "star fish" in English).
• Subs and methods that are automatically called for you at special times are written in uppercase. This includes the MAIN sub, the AT-POS and related methods for implementing container types, along with BUILD and DESTROY.
• Type names are camel case, except for native types, which are lowercase (how to remember: they are stored in a more compact way, so they names look smaller too).
• Built-in dynamic variables and compile-time variables are always uppercase ($*OUT, $?FILE).
• Methods from the MOP and other internals use _ to separate multiple words.

[zoffixznet]

is-prime vs. deepmap vs. STORE
is there a report about rakudo name conventions? should we attempt to decide one?

Somewhat tangent to the original discussion, but I saw "naming" and "consistency" mentioned. I've been noting some of the language inconsistencies in hopes of ironing them out some day. Here's a list of the items concerning naming:

• IO::Socket has $.encoding and IO::Socket::INET does it, but IO::Socket::Async has $.enc for the same purpose
• IO::Handle also has $.encoding, but .open (and other methods) take :enc attribute.
  :enc is also taken by run()/shell() and Proc::Async has $.enc attribute
• run()/shell()/Proc::Async.start all take :cwd attribute. IO::Path.new takes :CWD attribute for the same purpose.
• run()/shell() take :env attribute. Proc::Async.start takes :ENV attribute for the same purpose.

[tisonkun]

Initial naming conventions documented by Raku/doc@8f4b7c8

[tisonkun]

closed as not a problem.

[AlexDaniel]

Transferring to problem-solving, even if we decided that it's not a problem.

[AlexDaniel]

Ah. I forgot, again. Nevermind!