PPC 0022 Metaprogramming API

[trapd00r]

I love this. Excellent!

[haarg]

In its current state, I have to vote no.

There are many ways in which this does not match with perl's own understanding of its internals. has_package is nonsensical in any real sense. Nothing in this proposal mentions GLOBs, which do exist, for better or worse. Why is get_variable different from get_subroutine? What about file handles? Nobody likes them, but they exist and don't have a sigil.

I would love a world where bareword filehandles didn't exist, and where packages could be said to "exist". But making an API that doesn't understand perl as it actually exists does not seem like the way to do that.

[leonerd]

There are many ways in which this does not match with perl's own understanding of its internals. has_package is nonsensical in any real sense.

Fair. That could either be solved by documentation ("This method is likely to return true in many cases you might not expect, so be careful"), or we could just skip it altogether and say that any package potentially does exist, and ->get_package autovivifies one if it previously didn't.

Nothing in this proposal mentions GLOBs, which do exist, for better or worse.

I did think about that. It could be possible to add a ->get_glob which returns a holder on a GV, and then the various ->get_symbol-type methods are just wrappers for fetching the appropriate slot out of a GV. Effectively something like the following:

method meta::package::get_symbol($name) {
  if($name =~ m/^\$(.*)/) { return $self->get_glob($1)->get_scalar_slot }
  elsif ...
}

I didn't want to complicate the user-visible API too much and have end-users have to think about globs, but maybe that should be exposed anyway but users encouraged to use the convenient wrapper ones...

Why is get_variable different from get_subroutine

A fair question. It probably doesn't have to be - perhaps they can both just be ->get_thing I just didn't have a good noun for what "thing" is. ;) They're not "symbol" because they could work on lexical variables, anon subs, all sorts of non-symbolic things.

What about file handles? Nobody likes them, but they exist and don't have a sigil.

Oooh fair. That further suggests that maybe the glob-shaped API as an intermediate step is the way forward.

I would love a world where bareword filehandles didn't exist, and where packages could be said to "exist". But making an API that doesn't understand perl as it actually exists does not seem like the way to do that.

Alright - I'm happy to make changes. As I said originally I didn't put a huge amount of thought into the first draft, so this sort of feedback is useful. Let me know what you think of the-above ideas and I'll have a bit of a rewrite.

[EvanCarroll]

It seems as if there is pushback against the package existence test. There are two other packages that play in this sphere,

• Package::Stash
• Class::MOP::Package

Moreover, there are some other things mentioned that are needed imho, like Sub::Util's

• prototype
• set_prototype
• subname
• set_subname

As a point of endorsement for this RFC, if Package::Stash, Class::MOP::Package and Sub::Util can be rewritten as shims on meta:: it has my endorsement.

Are there any remaining questions or concerns to be resolved if the part of this proposal pertaining to package existence is dropped?

---

I'd also like to get the signature through something provided in meta::. That conversation can be shelved for now, but this came up for me immediately and it stings not having an answer there. https://stackoverflow.com/q/63836449/124486

[leonerd]

I've adjusted several bits of wording, and added further thoughts about globs, etc.

I'd like to try to get a consensus on at least some of this, so I can begin actually writing code to try it out. A missing meta API is starting to get in the way of writing more interesting bits of behaviour around the new class feature, so I'd like to get something started somehow fairly soon; even if it's just sitting around as an external CPAN module initially.

[haarg]

We're likely to accept this PPC, although with a provision that the exact API is not settled yet. Since this will basically be a normal XS module, we can start by shipping some dev releases to CPAN to work towards a final API.

But in regards to CPAN, there is a complication. Permissions on CPAN are case insensitive, and the Meta module is already "taken". VELTZER has co-maint on the namespace, but does not have a Meta module. Instead, they have a dist named Meta that includes various modules under the Meta:: namespace. At the time of release, in 2002, they would not have been given permissions to the Meta namespace. But later, rules were introduced to require dist names match a package you have permission to. Older dists that hadn't followed this had their authors granted extra permissions to match their dist names.

I think it would be reasonable for us to take over this namespace. The author never actually used it, and is unlikely to ever do another release of their dist. And if they did want to do so, they could just rename the dist to match one of their modules. They don't need actual Meta namespace for anything.

This is something that should be discussed with PAUSE admins. Possibly @neilb can weigh in, as I know he was heavily involved in the dist name permissions resolution.

[leonerd]

While awaiting PAUSE permissions for actual indexing, I went ahead and created the release tarballs anyway and uploaded them...

Initial placeholder version, unindexed due to permissions errors https://metacpan.org/release/PEVANS/meta-0.001

Also devel version that actually has code: https://metacpan.org/release/PEVANS/meta-0.001_001

[leonerd]

PAUSE permissions have now been granted and reïndexed, so now this appears

https://metacpan.org/pod/meta

[leonerd]

It seems like this document is close enough for initial experimental work, but there are still many unresolved comments and issues around it.

We've now enabled Issues on the PPCs repository.

Overall the process should be split more between comments on the PR vs Issues, in that the PR is about adding a proposed perl change. Just because a document is committed in the repository does not mean that the underlying idea it describes has been accepted as an idea. Comments on the PR should be reserved for surface-level issues to do with document formatting, spelling, clarity of language, etc... Wider thoughts about the validity of the idea itself can now be discussed by opening an issue, to discuss a PPC document.

Therefore, I think we should merge this document as it stands - its status is still marked "Exploratory". If people have comments about the actual ideas presented here, it would be best to open individual Issues (make sure to begin the issue title with "PPC 0022") so they can be looked at and tracked invididually.