Routines supplied by class Cool/ Any/ Mu

[ElenaMerelo]

From my point of view, I think it would be better if the routines or method from the classes mentioned above were not included and explained in each and every class that inherits from them, and instead just show the methods which are unique to the class.

[JJ]

It's probably sensible to not go all the way down to Mu in all pages. Not good SEO, either. Any other opinion?

[jnthn]

The default for .^methods and related bits of introspection is to hide things from Any, Cool, and Mu by default, so there's at least precedent for doing that (there's also :all for asking for those to be included).

[MattOates]

Just to add to this, I think its more confusing to include Any/Cool/Mu than it is helpful. For example what does .sort from Any actually mean for using say Proc::Async? It adds to confusion of the function and meaning of a class by presenting a lot of the more internal methods that make Perl 6 work rather than are specific to the class you are looking at.

[JJ]

There's going to be a problem now with hash-links from other pages. I have seen at least one. We'll have to fix them on a one by one basis. Also refs #561

[zoffixznet]

IMO this change is ill-considered and is causing real-world user confusion as new users are reading code samples and trying to look up the methods in the docs and fail to find them. I think that's far more important than purely speculative conjectures about "not good SEO".

Even with more experienced users it's now tougher to find which type in the inheritance chain overrides the method. If I'm trying to lookup gist and do an in-page search that turns up nothing does that mean the class uses Mu.gist or did I make a typo in my search term?

above were not included and explained in each and every class that inherits from them

The Any/Mu docs were tacked away at the bottom—you don't have to read them if you don't want to. The Type docs are reference docs but this change made it so you have to look up three different pages to figure out what provides a particular method—and that's only if you already know most objects inherit from Any/Mu and that Any/Mu methods aren't listed on individual pages since, confusingly, inherited methods from all other types are listed.

For example what does .sort from Any actually mean for using say Proc::Async?

Well, exactly! What does it mean? What answer does the Proc::Async documentation now give? It doesn't give any. And If someone is reading a piece of code that's calling .sort on a variable with a Proc::Async object, they now have a difficult time trying to find that information.

I don't follow that argumentation at all. If it's not clear what Any.sort does with Proc::Async, fix the documentation of Any.sort instead of pretending the method that's inherited by a type doesn't exist.