view release on metacpan or  search on metacpan

share/Apocalypse/A12.pod  view on Meta::CPAN

"definitely has one or more methods in one or more classes that will
try to handle this."  But that's probably closer to what you want,
and the best we can do when people start fooling around with wildcard
methods under MI.

However, that being said, many classes may wish to dynamically
specify at the last moment which methods they can or cannot handle.
That is, they want a hook to allow a class to declare names even while
the C<.can> candidate list is being built.  By default C<.meta.can>
includes all wildcard delegations and autoloads at the end of the list.
However, it will exclude from the list of candidates any class that
defines its own C<AUTOMETH> method, on the assumption that each
such C<AUTOMETH> method has already had its chance to add any
callable names to the list.  If the class's C<AUTOMETH> wishes to
supply a method, it should return a reference to that method.

Do not confuse C<AUTOMETH> with C<AUTOMETHDEF>.  The former is
equivalent to declaring a stub declaration.  The latter is equivalent
to supplying a body for an existing stub.  Whether C<AUTOMETH>
actually creates a stub, or C<AUTOMETHDEF> actually creates a body,
is entirely up to those routines.  If they wish to cache their results,
of course, then they should create the stub or body.

There are corresponding C<AUTOSUB> and C<AUTOSUBDEF> hooks.
And C<AUTOVAR> and C<AUTOVARDEF> hooks.  These all pretty much
make C<AUTOLOAD> obsolete.  But C<AUTOLOAD> is still there for old times's sake.

[Update: These are all subsumed into C<CANDO> multies and C<AUTODEF> submethods.]

=head1 Other Non-OO Decisions

A lot of time went by while I was in the hospital last year, so we
ended up polishing up the design of Perl 6 in a number of areas not
directly related to OO.  Since I've already got your attention
(and we're already 90% of the way through this Apocalypse), I might
as well list these decisions here.

=head2 Exportation

The trait we'll use for exportation (typically from modules but also
from classes pretending to be modules) is C<export>:

                                               # Tagset...
    sub foo is export(:DEFAULT)         {...}  #  :DEFAULT, :ALL
    sub bar is export(:DEFAULT :others) {...}  #  :DEFAULT, :ALL, :others
    sub baz is export(:MANDATORY)       {...}  #  (always exported)
    sub bop is export                   {...}  #  :ALL
    sub qux is export(:others)          {...}  #  :ALL, :others

Compared to Perl 5, we've basically made it easier to mark something
as exportable, but more difficult to export something by default.
You no longer have to declare your tagsets separately, since C<:foo>
parameters are self-declaring, and the module will automatically
build the tagsets for you from the export trait arguments.

=head2 The gather/take Construct

We used one example of the conjectural gather/take construct.  A gather
executes a closure, returning a list of all the values returned by
C<take> within its lexical scope.  In a lazy context it might run as
a coroutine.  There probably ought to be a dynamically scoped variant.
Unless it should be dynamic by default, in which case there probably
ought to be a lexically scoped variant...

=head2 :foo() Adverbs

There's a new pair syntax that is more conducive to use as option
arguments.  This syntax is reminiscent of both the Unix command
line syntax and the I/O layers syntax of Perl 5.  But unlike Unix
command-line options, we use colon to introduce the option rather than
the overly negative minus sign.  And unlike Perl 5's layers options, you
can use these outside of a string.

We haven't discarded the old pair syntax.  It's still more readable
for certain uses, and it allows the key to be a non-identifier.
Plus we can define the new syntax in terms of it:

    Old				New
    ---				---
    foo => $bar			:foo($bar)
    foo => [1,2,3,@many]	:foo[1,2,3,@many]
    foo => «alice bob charles»	:foo«alice bob charles»
    foo => 'alice'		:foo«alice»
    foo => { a => 1, b => 2 }	:foo{ a => 1, b => 2 }
    foo => { dostuff() }	:foo{ dostuff() }
    foo => 0			:foo(0)
    foo => 1			:foo

It's that last one that's the real winner for passing boolean options.
One other nice thing is that if you have several options in a row you
don't have to put commas between:

    $handle = open $file, :chomp :encoding«guess» :ungzip or die "Oops";

It might be argued that this conflicts the :foo notation for private
methods.  I don't think it's a problem because method names never
occur in isolation.

[Update: We ended up changing private methods to use C<!> instead.  Also,
there's a C<:!foo> form to mean C<:foo(0)>.]

Oh, one other feature of option pairs is that certain operations can
use them as adverbs.  For instance, you often want to tell the range
operator how much to skip on each iteration.  That looks like this:

    1..100 :by(3)

Note that this only works where an operator is expected rather than a term.
So there's no confusion between:

    randomlistop 1..100 :by(3)

and

    randomlistop 1..100, :by(3)

In the latter case, the option is being passed to C<randomlistop()>
rather than the C<infix:..> operator.

[Update: That's C<< infix:<..> >> now.]

share/Apocalypse/A12.pod  view on Meta::CPAN

if you want the length of something in characters you use

    my $sizeinchars = chars($string);

and if you want the size in elements, you use

    my $sizeinelems = elems(@array);

This is more orthogonal in some ways, insofar as you can now ask for
the size in chars of an array, and it will add up all the lengths of
the strings in it for you:

    my $sizeinchars = chars(@array);

And if you ask for the number of elems of a scalar, it knows to
dereference it:

    my $ref = [1,2,3];
    my $sizeinelems = elems($ref);

These are, in fact, just generic object methods:

    @array.elems
    $string.chars
    @array.chars
    $ref.elems

And the functional forms are just multimethod calls.  (Unless they're
indirect object calls...who knows?)

You can also use C<%hash.elems>, which returns the number of pairs in
the hash. I don't think C<%hash.chars> is terribly useful, but it will
tell you how many characters total there are in the values.  (The key
lengths are ignored, just like the integer "keys" of an ordinary array.)

Actually, the meaning of C<.chars> varies depending on your current
level of Unicode support. To be more specific, there's also:

    $string.bytes
    $string.codepoints
    $string.graphemes
    $string.letters

[Update: Those are shortened to C<.codes>, C<.graphs>, and C<.langs> now.]

...none of which should be confused with:

    $string.columns

or its evil twin:

    $string.pixels

Those last two require knowledge of the current font and rendering
engine, in fact.  Though C<.columns> is likely to be pretty much the
same for most Unicode fonts that restrict themselves to single and
double-wide characters.

=head2 String positions

A corollary to the preceding is that string positions are not numbers.
If you say either

    $pos = index($string, "foo");

or

    $string ~~ /foo/; $pos = $string.pos;

then C<$pos> points to that location in that string.  If you ask for
the numeric value of C<$pos>, you'll get a number, but which number you
get can vary depending on whether you're currently treating characters
as bytes, codepoints, graphemes, or letters.  When you pass a C<$pos>
to C<substr($string, $pos, 3)>, you'll get back "C<foo>", but not
because it counted over some number of characters.  If you use C<$pos>
on some other string, then it has to interpret the value numerically
in the current view of what "character" means.  In a boolean context,
a position is true if the position is defined, even if that position
would evaluate to 0 numerically.  (C<index> and C<rindex> return undef
when they "run out".)

And, in fact, when you say C<$len = .chars>, you're really getting
back the position of the end of the string, which just happens to
numerify to the number of characters in the string in the current view.
A consequence of the preceding rules is that C<"".chars> is true,
but C<+"".chars> is false.  So Perl 5 code that says C<length($string)>
needs to be translated to C<+chars($string)> if used in a boolean
context.

Routines like C<substr> and C<index> take either positions or integers
for arguments.  Integers will automatically be turned into positions
in the current view.  This may involve traversing the string for
variable-width representations, especially when working with combining
characters as parts of graphemes.  Once you're working with abstract
positions, however, they are efficient.  So

    while $pos = index($string, "fido", $pos + 1) {...}

never has to rescan the string.

The other point of all this is that you can pass C<$pos> or C<$len> to
another module, and I<it doesn't matter> if you're doing offsets in
graphemes and they are doing offsets in codepoints.  They get the
correct position by their lights, even though the number of characters
looks different.  The main constraint on this is that if you pass
a position from a lower Unicode support level to a higher Unicode
support level, you can end up with a position that is inside what
you think of as a unitary character, whether that's a byte within a
codepoint, or a codepoint within a grapheme or letter. If you deref
such a position, an exception is thrown.  But generally high-level
routines call into low-level routines, so the issue shouldn't arise
all that often in practice.  However, low-level routines that want
to be called from high-level routines should strive not to return
positions inside high-level characters--the fly in the ointment being
that the low-level routine doesn't necessarily know the Unicode level
expected by the calling routine.  But we have a solution for that...

High-level routines that suspect they may have a "partial position" can
call C<$pos.snap> (or C<$pos.=snap>) to round up to the next integral
position in the current view, or (much less commonly) C<$pos.snapback>
(or C<$pos.=snapback>) to round down to the next integral position