Skip to content
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

Add Metamodel::EnumHOW page #1648

Merged
merged 1 commit into from Nov 4, 2017
Merged

Add Metamodel::EnumHOW page #1648

merged 1 commit into from Nov 4, 2017

Conversation

bduggan
Copy link
Member

@bduggan bduggan commented Nov 3, 2017

This adds a page for MetaModel::EnumHOW. Looking for feedback -- I took these from the source, though I don't think they are part of the spec, so not sure if it's appropriate to list them here? (Or maybe there should be a note about them being rakudo-specific?)

Resolves #1642

@jnthn
Copy link
Contributor

jnthn commented Nov 4, 2017

I think it's OK to document the MOP, in general. It may not all be spec, but in reality it's one of the most stable parts of the Rakudo implementation. Future Perl 6 implementations will need to implement a MOP too, and whether we document the Rakudo one or not, people will discover and use it anyway, which will probably make it a de facto standard. That usage will in turn probably drive us to spec increasing amounts of it, to make sure we aren't breaking the ecosystem.

@AlexDaniel
Copy link
Member

All these underscores tho… :S

@AlexDaniel
Copy link
Member

Anyway, we already have ClassHOW so adding EnumHOW won't hurt (although both pages should probably have a warning of some sort).

@AlexDaniel AlexDaniel merged commit 310efd3 into master Nov 4, 2017
@geekosaur
Copy link

(Summary of discussion on IRC)

I would be very cautious about adding things to the spec that could tie you to a particular implementation. Documenting such is fine, but should include warnings that they are not part of the spec and are use-at-your-own-risk.

I mean, there are already modules in the ecosystem that dive into nqp; does that now become a spec candidate because of the potential breakage?

At some point in the future, a limited public API/spec for the MOP might be an idea; I personally would want to see a bit more experience and preferably other implementations before committing to one, though.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants