Auth/Ver information is UNIT based, but specced as class etc. Propose -unit-

[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.

[FROGGS]

+1 though I'd say that auth/ver makes sense for the semicolon form of class/package/... .

Only for the BLOCK form it is sort of misleading and wrong.

Having an additional unit statement makes sense when you have more that one BLOCK form, and it makes clear what nested classes/packages/... mean by auth/ver.

[lizmat]

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).

[lizmat]

[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

[lizmat]

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:

1. -use- cannot differentiate between module/class/grammar, so you still would not know what you're really loading.
2. it will load any other code in that file as well. This may be nothing at all, or it may be a whole library of modules.
3. it would be hard to not introduce any load order dependent artefacts.

[lizmat]

Please see 4425736dd2 for a first attempt at unslushing S11

[lizmat]

Some more changes, one probably needs to look at https://github.com/perl6/specs/blob/master/S11-modules.pod

[supernovus]

Definitely like the use of Pod for the versioning meta data instead of the previously proposed unit statement! Nice work lizmat++