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