-
Notifications
You must be signed in to change notification settings - Fork 36
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
Auth/Ver information is UNIT based, but specced as class etc. Propose -unit- #54
Comments
+1 though I'd say that auth/ver makes sense for the Only for the Having an additional |
Even if it would sort of make sense for the semicolon from of class/package/... , it would still be incorrect, as the -use- statement selects a file to load, and therefore a unit. I think this needs to be reinforced in the developer's mind. And therefore, a separate -unit- statement would make sense as the only place to specify auth/ver information. On top of that, but that's just a side-effect, it will make it easier for installers / packagers to find out auth/ver information from a file. And unambiguously so (which multiple class type statements with conflicting auth/ver information would not be). |
[12:22:48] <masak> lizmat: also worth thinking about in the memespace around #54 is how Perl 6 sees the distinction between "modules" (essentially the 'unit' keyword you're proposing) and "distributions" (a CPAN concept which can contain zero or more modules). [13:31:41] <lizmat> masak: a unit may contain multiple modules. A distribution may contain multiple units. It's up to the author whether to separate modules over multiple units (allowing them different auth/ver information), or keep them in one unit (forcing the modules to share auth/ver infomation). [13:33:04] <lizmat> the advantage of keeping them in one unit, is that these modules can easily share variables and internal subroutines |
Thinking about it more, there is one alternative, but that may be more fragile. Suppose the -use- command will know which file to load for a given package name. In other words, the cached install information of files in each @inc directory would know which file contained which package-like statement. However, I see several problems with that approach:
|
Please see 4425736dd2 for a first attempt at unslushing S11 |
Some more changes, one probably needs to look at https://github.com/perl6/specs/blob/master/S11-modules.pod |
Definitely like the use of Pod for the versioning meta data instead of the previously proposed unit statement! Nice work lizmat++ |
The current spec at S11:363 indicates that version/auth information of a class/module/grammar/role should be specified in the statement, e.g.
class Dog:authcpan:JRANDOM:ver<1.2.1>;
However, its counterpart:
use Dog:authcpan:JRANDOM:ver<1.2.1>;
applies to a file, therefore a UNIT, and to all code residing in that file, regardless of what is in there. In other words: -use- is just a way of smartfinding a file to load the code of.
I've therefore come to the conclusion that we need to make this more generic, and that we should have a way to identify the unit, rather than anything inside it.
I therefore propose to remove all auth/ver related information from class/module/grammar and the like, and create a new statement "unit":
unit Dog:authcpan:JRANDOM:ver<1.2.1>;
Only one -unit- statement would be valid per file. And it would be used by packagers / installers to let the system know what it is.
It should probably only be legal when reading from a file, although I could see uses for "eval" as well.
I think this would make things a lot clearer than the current specification.
The text was updated successfully, but these errors were encountered: