Re: r27312 - docs/Perl6/Spec
On Mon, Jun 29, 2009 at 09:14:10PM -0700, Darren Duncan wrote: pugs-comm...@feather.perl6.nl wrote: +When it happens that the same module is available from more than one +authority, and the desired authority is not specified by the Cuse, +the version lineage that was created first wins, unless overridden by +local policy or by official abandonment by the original authority (as +determined either by the author or by community consensus in case the +author is no longer available or widely regarded as uncooperative). +An officially abandoned lineage will be selected only if it is the +only available lineage of locally installed modules. + +Once the authority is selected, then and only then is any version +selection done; the version specification is ignored until the +authority is selected. This implies that all official modules record +permanently when they were first installed in the official library, +and this creation date is considered immutable. + For wildcards any valid smartmatch selector works: use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/); So now you've explicitly stated what I implicitly (or maybe explicitly) thought before, in that version numbers are always subordinate to authorities, and only make sense in the context of an authority, though an explicit authority doesn't have to be declared in user code. I propose that the canonical order of entity long names be altered so that the :auth always comes first, and :ver second, when both are used. For example: use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4); The documentation should be in that order, not the other order. Then I think the syntax better corresponds to the actual interpretation, conceptually where each new trait (or trait-looking thing) is interpreted in the context of those before it. And I don't just mean example code, but explanation order too. I agree, and since you've got a pugs commit bit, feel free to fix it if I don't get to it. I've got about three other fundamental design issues distracting me at the moment, alas... Larry
r27312 - docs/Perl6/Spec
Author: lwall Date: 2009-06-30 01:44:51 +0200 (Tue, 30 Jun 2009) New Revision: 27312 Modified: docs/Perl6/Spec/S11-modules.pod Log: [S11] some notes on ambiguous authority specs Modified: docs/Perl6/Spec/S11-modules.pod === --- docs/Perl6/Spec/S11-modules.pod 2009-06-29 22:40:43 UTC (rev 27311) +++ docs/Perl6/Spec/S11-modules.pod 2009-06-29 23:44:51 UTC (rev 27312) @@ -12,8 +12,8 @@ Created: 27 Oct 2004 -Last Modified: 30 Mar 2009 -Version: 28 +Last Modified: 29 Jun 2009 +Version: 29 =head1 Overview @@ -401,6 +401,21 @@ to guarantee that you get the unembraced Perl. C:-) +When it happens that the same module is available from more than one +authority, and the desired authority is not specified by the Cuse, +the version lineage that was created first wins, unless overridden by +local policy or by official abandonment by the original authority (as +determined either by the author or by community consensus in case the +author is no longer available or widely regarded as uncooperative). +An officially abandoned lineage will be selected only if it is the +only available lineage of locally installed modules. + +Once the authority is selected, then and only then is any version +selection done; the version specification is ignored until the +authority is selected. This implies that all official modules record +permanently when they were first installed in the official library, +and this creation date is considered immutable. + For wildcards any valid smartmatch selector works: use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/);
Re: r27312 - docs/Perl6/Spec
pugs-comm...@feather.perl6.nl wrote: +When it happens that the same module is available from more than one +authority, and the desired authority is not specified by the Cuse, +the version lineage that was created first wins, unless overridden by +local policy or by official abandonment by the original authority (as +determined either by the author or by community consensus in case the +author is no longer available or widely regarded as uncooperative). +An officially abandoned lineage will be selected only if it is the +only available lineage of locally installed modules. + +Once the authority is selected, then and only then is any version +selection done; the version specification is ignored until the +authority is selected. This implies that all official modules record +permanently when they were first installed in the official library, +and this creation date is considered immutable. + For wildcards any valid smartmatch selector works: use Dog:ver(v1.2.1 | v1.3.4):auth(/:i jrandom/); So now you've explicitly stated what I implicitly (or maybe explicitly) thought before, in that version numbers are always subordinate to authorities, and only make sense in the context of an authority, though an explicit authority doesn't have to be declared in user code. I propose that the canonical order of entity long names be altered so that the :auth always comes first, and :ver second, when both are used. For example: use Dog:auth(/:i jrandom/):ver(v1.2.1 | v1.3.4); The documentation should be in that order, not the other order. Then I think the syntax better corresponds to the actual interpretation, conceptually where each new trait (or trait-looking thing) is interpreted in the context of those before it. And I don't just mean example code, but explanation order too. -- Darren Duncan
