Open JJ opened 4 years ago
vrurg
commented
4 years ago A common term for just two entities? Does it really makes sense? Besides, the only thing they have in common is that they somehow modify class behavior.
Though, if choosing among the option would be mandatory, I'd go for shapers or modifiers.
JJ
commented
4 years ago El vie., 18 oct. 2019 a las 16:29, Vadim Belman (notifications@github.com) escribió:
A common term for just two entities? Does it really makes sense? Besides, the only thing they have in common is that they somehow modify class behavior.
Well, besides being methods that you can add to any class, just like phasers. Actually, the term should include also phasers, or even things like AT-KEY which don't have a name yet.
Though, if choosing among the option would be mandatory, I'd go for shapers or modifiers.
modifiers should go with some qualifiers. So, anyone else for shapers?
tmtvl
commented
4 years ago Well, FALLBACK is practically a type of exception handling for invalid method call exceptions. It doesn't really change the shape of the object. CALL-ME is part of the Callable role, it's what makes the object that is a subroutine behave the way it does. So I don't really see the relation between them, apart from both being methods that get called discreetly rather than overtly.
vendethiel
commented
4 years ago Python and PHP call them "magic methods". (Though Python also calls them "Dunder" methods because they have a special naming convention).
JJ
commented
4 years ago El vie., 18 oct. 2019 a las 18:37, Tim Van den Langenbergh (< notifications@github.com>) escribió:
Well, FALLBACK is practically a type of exception handling for invalid method call exceptions. It doesn't really change the shape of the object. CALL-ME is part of the Callable role, it's what makes the object that is a subroutine behave the way it does.
It's that, but you can create CALL-ME on any object to give it the callable syntax. That's why one of the proposed names was "syntaxer"
vrurg
commented
4 years ago AT-KEY, AT-POS make a good company to the rest.
Why syntaxers isn't a good one is because FALLBACK doesn't actually change the syntax of using a class. It rather responsible for class behavior.
Why I like shapers is because those methods rather give the final "shape" to a class. Yet, I still have a feeling that there is better term for them.
@JJ, if the right term is chosen are there plans for a corresponding section in the docs?
JJ
commented
4 years ago @vrurg it would go to the glossary and then of course it would have a category in the documentation index and maybe a specific section.
coke
commented
2 years ago Looking back through the comments on this ticket, I see a question asked about why we need a common name for these two items, but not a response that answers that particular question.
Without a driving force to create this, I would recommend we close this ticket.
raiph
commented
2 years ago Hi @coke,
I'd like to "take" this ticket as the "driver" and see how I do.
If there's some particular thing I'm supposed to do to "take" this ticket other than just progress it as I see fit, please let me know what that is in as brief a way as you can manage. TIA.
Feel free to skip reading the rest of this comment, and indeed ignore this issue from here on, at least until I produce an associated PR or @mention you.
My proposal is that I'll either close this issue with no action (ie act as you recommend if there's no "driving force") or close it with:
A new term and entry added to the glossary;
New uses of the term in at least three other places, namely pages documenting FALLBACK, CALL-ME and phasers.
I could do more, such as using the term on more pages, adding it as a category, and so on, but currently think I'll postpone such things until I've closed this issue.
I see a question asked about why we need a common name for these two items
To be fair, JJ wrote:
Actually, the term should include also phasers, or even things like AT-KEY which don't have a name yet.
Again, feel free to skip reading the rest of this comment. It's just my discussion of the terms "magic methods" and "hooks" and a concluding strawman proposal that I plan to act on by default if no one pipes up in the next week or so.
Putting aside phasers, I'd say Vendethiel was spot on, in that Python and PHP use the term "magic methods" for exactly the kinds of methods JJ mentioned (before JJ added phasers to the mix).
So perhaps we adopt the same term "magic methods" (and skip lumping phasers in with magic methods, because that would be confusing).
Then again, googles like "avoid magic methods" suggest that enough devs have negative associations with "magic methods" that perhaps we should avoid using their term.
Aiui the negative association is due to problems with the specifics of particular magic methods in other PLs, not the general technique. But if Raku sticks with the same term I think folk will apply their negative associations to Raku even if it makes infinitely better use of the technique than Python. So I'm thinking the right solution here will be to introduce a new term, and mention magic methods in Python/PHP (because that is a good reference point) but find a way to do that without dragging in undue negative associations.
The traditional fully generic term is "hooks".
This term has the upsides that it avoids the word "magic", and would naturally cover phasers too, and could cover other hooks in Raku too (eg traits).
Then again, "hooks" might be too broad, perhaps far too broad.
For starters, it refers to hooks in any software system, not just a programming language or PL related artifact such as a library or API.
But even if one ignores that, I think it would essentially force us to lump in any other Raku feature that is, after all, a hook. If it walks and talks like a hook, it will be hard to deny it's a hook. Definitely traits, for example. Any others you can think of?
I could extend the word search to come up with something narrower than hooks. But I'm currently thinking "hooks" might work well, and this comment is already long. So...
The word is "hooks".
The glossary description is:
Hook. Raku contains a broad range of hooks that let you write custom handling that gets automatically invoked as Raku processes particular aspects of code. Raku's hooks include equivalents of the "magic methods" / "dunders" in PLs like Python/PHP (but avoiding their downsides) plus features such as Phasers and traits.
JJ
commented
2 years ago What about AT-KEY? Does not look so much a hook as a Magic method.
raiph
commented
2 years ago Hi @JJ,
Thanks for feedback. :)
AT-KEY is absolutely a magic method, as are BUILD and cousins (well, that strays into method or submethod of course), and even methods like ^parameterize.
Otoh, phasers aren't methods.
We could perhaps include phasers if we made the generic term something like "magic code". "code" would generalize to cover not only non-method hooks like CATCH { ... }, but also non-routine non-function thunkish scenarios like now - INIT now, compile-time declaration hooks (traits), and, well, the term could cover any and all hooks. (I note you seem to be thinking of things as being magic methods vs hooks, but instead it's that magic methods are one of many kinds of hook, which is the generic term for "magic code" and any other, well, hook.)
That said, I'm currently leery of any term with the word "magic" in it due to how many devs I see apparently successfully propagating the meme that "magic" is a bad thing, period, without any attention paid to what the term refers to.
The traditional fully generic industry standard term for "magic code" was, for many decades, "hooks".
One possibility I was mulling was having a Hooks page with sub-sections that include these:
ALLCAPS hooks. This covers hooks in Raku that are ALLCAPS methods/functions/statements/thunks, encompassing Raku's ALLCAPS "magic methods" as well as its uppercase phasers.)
MOP ^hooks. This covers MOP hooks such as ^parameterize.
Compile-time traits. This covers stuff like trait mods, including will which also involves phasers.
Or perhaps N separate pages that are all somehow tagged with a hook category?
These two methods basically add syntactic sugar to objects and classes: in one case, they can create on the fly methods that do not exist, in the other give an object the power to use () so that it becomes a functor. As far as I know, there's no generic name for this kind of thing, but then, there was no generic name for phasers before they were introduced in Perl. Giving stuff a name helps, among other things, to document it (which is why I gave it that label), but also creates a concept that can be later on filled with other things. So as long as we have agreed that we need a name, what would that name be?
Any other idea?