New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which metamodel roles are specced; which ought to be? #402
Comments
@jnthn would you be able to say which of these should be part of the spec? |
Well, per Hyrum's law, they'll probably all converge on being de facto spec if they don't change for long enough. :-) That aside, I'm a bit conflicted on this matter. Points for putting these in spec and doc are:
Points against putting these in spec/doc are:
None of these points feels to me to give a clear answer either way. I can argue all of "let's spec/doc it, to make meta-programming more accessible", "let's wait until we've more concrete usages to see if this is right", and "let's not tie our hands for the future and put off specifying it indefinitely". I suspect my opening point means the latter isn't an option we get to pick, though, which leaves "do it now" or "agree it should happen at some unspecified time in the future". 7ish years on from doing the original metamodel design, I don't really look at it and see a bunch of things that I wish were different. I do wonder if method caching needs a revisit, because the pre-computation of caches is expensive at startup time (deserializing those is probably the second biggest chunk of startup deserialization cost). But that wouldn't be especially disruptive to do within the current design anyway, and perhaps we can put more laziness smarts into MoarVM anyway and so not touch things at the Rakudo level at all. So even there I don't feel like specifying this would be tying my hands on changes I'd like to see. So, perhaps we shouldn't let the perfect be the enemy of the good and spec the roles. Who knows, maybe having people base their custom meta-objects around of set of core roles we have control over will afford the Rakudo team, and future implementations, more flexibility in the long run anyway. |
Following the discussion at Raku/doc#1846, I'm raising this ticket to ask which metamodel roles ought to be specced (but currently aren't) so that we can distinguish Rakudo-specific implementation details from the language specification proper.
The PR/issue linked above can be summarised as an attempt to (sparsely) document
Metamodel::ModuleHOW
and its roles (Metamodel::PackageHOW
is effectively a subset). These are:Metamodel::Documenting
Metamodel::MethodDelegation
Metamodel::Naming
Metamodel::Stashing
Metamodel::TypePretense
Metamodel::Versioning
It's not clear to me whether decomposition of metaclasses into named roles is specced or a Rakudo implementation detail. So: Should we be documenting the individual roles at all?
Metamodel::Documenting
WHY
Metamodel::MethodDelegation
find_method
Metamodel::Naming
name
Metamodel::Versioning
auth
andver
Metamodel::TypePretense
type_check
ClassHOW
andEnumHOW
.ModuleHOW
andPackageHOW
which avoid referencing Rakudo-specific details.Thanks!
The text was updated successfully, but these errors were encountered: