Author: lwall
Date: 2009-05-01 00:37:09 +0200 (Fri, 01 May 2009)
New Revision: 26591
Modified:
docs/Perl6/Spec/S01-overview.pod
docs/Perl6/Spec/S02-bits.pod
docs/Perl6/Spec/S03-operators.pod
docs/Perl6/Spec/S04-control.pod
docs/Perl6/Spec/S05-regex.pod
docs/Perl6/Spec/S06-routines.pod
docs/Perl6/Spec/S09-data.pod
docs/Perl6/Spec/S10-packages.pod
docs/Perl6/Spec/S11-modules.pod
docs/Perl6/Spec/S12-objects.pod
docs/Perl6/Spec/S13-overloading.pod
docs/Perl6/Spec/S14-roles-and-parametric-types.pod
docs/Perl6/Spec/S22-package-format.pod
docs/Perl6/Spec/S32-setting-library/Basics.pod
Log:
get rid of the term "protoobject" in favor of "type object" or just "type"
get rid of redundant and confusing Number: lines
Modified: docs/Perl6/Spec/S01-overview.pod
===================================================================
--- docs/Perl6/Spec/S01-overview.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S01-overview.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -13,7 +13,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 10 Aug 2004
Last Modified: 30 Jan 2007
- Number: 1
Version: 6
This document originally summarized Apocalypse 1, which covers the
Modified: docs/Perl6/Spec/S02-bits.pod
===================================================================
--- docs/Perl6/Spec/S02-bits.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S02-bits.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -12,9 +12,8 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 10 Aug 2004
- Last Modified: 24 Apr 2009
- Number: 2
- Version: 166
+ Last Modified: 30 Apr 2009
+ Version: 167
This document summarizes Apocalypse 2, which covers small-scale
lexical items and typological issues. (These Synopses also contain
@@ -520,7 +519,7 @@
# and is implemented by the MyScalar class
my Int $x is MyScalar;
-Note that C<$x> is also initialized to the C<Int> protoobject. See below for
more on this.
+Note that C<$x> is also initialized to the C<Int> type object. See below for
more on this.
=item *
@@ -534,15 +533,15 @@
say $spot; # "Dog"
Any type name used as a value is an undefined instance of
-that type's prototype object, or I<protoobject>. See S12 for more on that.
-Any type name in rvalue context is parsed as a single protoobject value and
-expects no arguments following it. However, a protoobject responds to the
function
-call interface, so you may use the name of a protoobject with parentheses as
if it
+that type's prototype object, or I<type object> for short. See S12 for more
on that.
+Any type name in rvalue context is parsed as a single type value and
+expects no arguments following it. However, a type object responds to the
function
+call interface, so you may use the name of a type with parentheses as if it
were a function, and any argument supplied to the call is coerced
-to the type indicated by the protoobject. If there is no argument
-in the parentheses, the protoobject returns itself:
+to the type indicated by the type object. If there is no argument
+in the parentheses, the type object returns itself:
- my $type = Num; # protoobject as a value
+ my $type = Num; # type object as a value
$num = $type($string) # coerce to Num
To get a real C<Dog> object, call a constructor method such as C<new>:
@@ -938,7 +937,7 @@
are handled.)
Nil Empty list viewed as an item
- Object Uninitialized (derivatives serve as protoobjects of classes)
+ Object Uninitialized (derivatives serve as type objects)
Whatever Wildcard (like undef, but subject to do-what-I-mean via MMD)
Failure Failure (lazy exceptions, thrown if not handled properly)
@@ -1386,8 +1385,9 @@
to support C<< postcircumfix:<( )> >>.
C<::x> may be bound to any object that does the C<Abstraction> role,
-such as a typename, package, module, class, role, grammar, or any other
-protoobject with C<.HOW> hooks. This C<Abstraction> role implies the
+such as a package, module, class, role, grammar, or any other
+type object, or any immutable value object that can be used as a type.
+This C<Abstraction> role implies the
ability to do various symbol table and/or typological manipulations which
may or may not be supported by any given abstraction. Mostly though it
just means that you want to give some abstraction an official name that
@@ -1967,9 +1967,9 @@
PROCESS::<$IN> # Same as $*IN
Foo::<::Bar><::Baz> # same as Foo::Bar::Baz
-The C<::> before the subscript is required here, because the C<Foo::Bar{...}>
-syntax is reserved for defining an autovivifiable protoobject along with
-its initialization closure (see S12).
+The C<::> before the subscript is required here, because the
+C<Foo::Bar{...}> syntax is reserved for attaching a "WHENCE"
+initialization closure to an autovivifiable type object. (see S12).
Unlike C<::()> symbolic references, this does not parse the argument
for C<::>, nor does it initiate a namespace scan from that initial
@@ -3457,18 +3457,21 @@
=item *
Unlike in Perl 5, objects are no longer always considered true.
-It depends on the state of their C<.true> property. Classes get to decide
+It depends on the state of their C<.Bool> property. Classes get to decide
which of their values are true and which are false. Individual objects
can override the class definition:
return 0 but True;
+This overrides the C<.Bool> method of the C<0> without changing its
+official type (by mixing the method into an anonymous derived type).
+
=item *
-The definition of C<.true> for the most ancestral type (that is, the
-C<Object> type) is equivalent to C<.defined>. Since protoobjects are
-considered undefined, all protoobjects (including C<Object> itself)
-are false unless the type overrides the definition of C<.true>
+The definition of C<.Bool> for the most ancestral type (that is, the
+C<Object> type) is equivalent to C<.defined>. Since type objects are
+considered undefined, all type objects (including C<Object> itself)
+are false unless the type overrides the definition of C<.Bool>
to include undefined values. Instantiated objects default to true
unless the class overrides the definition. Note that if you could
instantiate an C<Object> it would be considered defined, and thus true.
Modified: docs/Perl6/Spec/S03-operators.pod
===================================================================
--- docs/Perl6/Spec/S03-operators.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S03-operators.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -12,9 +12,8 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 8 Mar 2004
- Last Modified: 19 Apr 2009
- Number: 3
- Version: 163
+ Last Modified: 30 Apr 2009
+ Version: 164
=head1 Overview
@@ -3468,11 +3467,12 @@
($a,$b,$c) »+=» 1; # add one to each of three variables
-If you apply an assignment operator to a protoobject, it is assumed that
+If you apply an assignment operator to a container containing a type object
+(which is undefined), it is assumed that
you are implementing some kind of notional "reduction" to an accumulator
variable. To that end, the operation is defined in terms
-of the corresponding reduction operator, where the protoobject
-becomes the operator's identify value. So if you say:
+of the corresponding reduction operator, where the type object
+autovivifies to the operator's identify value. So if you say:
$x -= 1;
@@ -4095,7 +4095,7 @@
containers that do not support the concept of undefined should be
initialized to 0 instead. (Native floating-point containers are
by default initialized to C<NaN>.) Typed object containers start
-out containing an undefined protoobject of the correct type.
+out containing an undefined type object of the correct type.
List-context pseudo-assignment is supported for simple declarations but
not for signature defaults:
@@ -4112,8 +4112,9 @@
constant Dog $fido = $fido.new; # wrong: invalid self-reference
constant (Dog $fido .= new); # wrong: cannot use .= with parens
-Note that very few mutating operators make sense on a protoobject, however,
-since protoobjects are a kind of undefined object.
+Note that very few mutating operators make sense on a type object, however,
+since type objects are a kind of undefined object. (Those operators with
+an identity value are an exception, as noted above.)
Parentheses must always be used when declaring multiple parameters:
Modified: docs/Perl6/Spec/S04-control.pod
===================================================================
--- docs/Perl6/Spec/S04-control.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S04-control.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -13,7 +13,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 19 Aug 2004
Last Modified: 19 Apr 2009
- Number: 4
Version: 76
This document summarizes Apocalypse 4, which covers the block and
Modified: docs/Perl6/Spec/S05-regex.pod
===================================================================
--- docs/Perl6/Spec/S05-regex.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S05-regex.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -15,7 +15,6 @@
Larry Wall <la...@wall.org>
Date: 24 Jun 2002
Last Modified: 29 Apr 2009
- Number: 5
Version: 96
This document summarizes Apocalypse 5, which is about the new regex
Modified: docs/Perl6/Spec/S06-routines.pod
===================================================================
--- docs/Perl6/Spec/S06-routines.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S06-routines.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -14,7 +14,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 21 Mar 2003
Last Modified: 9 Apr 2009
- Number: 6
Version: 108
@@ -424,7 +423,7 @@
does not have references in the same sense that Perl 5 does.)
To allow modification, use the C<is rw> trait. This requires a mutable
-object or container as an argument (or some kind of protoobject that
+object or container as an argument (or some kind of type object that
can be converted to a mutable object, such as might be returned
by an array or hash that knows how to autovivify new elements).
Otherwise the signature fails to bind, and this candidate routine
Modified: docs/Perl6/Spec/S09-data.pod
===================================================================
--- docs/Perl6/Spec/S09-data.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S09-data.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -12,9 +12,8 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 13 Sep 2004
- Last Modified: 6 Apr 2009
- Number: 9
- Version: 32
+ Last Modified: 30 Apr 2009
+ Version: 33
=head1 Overview
@@ -1242,13 +1241,13 @@
%hash<foo><bar> = "foo"; # duh
This rule applies to C<Array>, C<Hash>, and any other container type that
-chooses to return an autovivifiable protoobject (see S12) rather than simply
+chooses to return an autovivifiable type object (see S12) rather than simply
returning C<Failure> when a lookup fails. Note in particular that, since
-autovivification is defined in terms of protoobjects rather than failure,
+autovivification is defined in terms of type objects rather than failure,
it still works under "use fatal".
This table solidifies the intuition that an operation pertaining to some data
-structure causes the protoobject to autivivify to such an object:
+structure causes the type object to autivivify to such an object:
operation autovivifies to
========= ===============
@@ -1260,22 +1259,25 @@
natural consequences of the operators working on C<Failure>, qualitatively
different from autovivifying containers.
-The type of the protoobject returned by a non-successful lookup should
+The type of the type object returned by a non-successful lookup should
be identical to the type that would be returned for a successful lookup.
+The only difference is whether it's officially instantiated (defined) yet.
+That is, you cannot distinguish them via C<.WHAT> or C<.HOW>, only via
+C<.defined>.
-Binding of an autovivifiable protoobject to a non-writeable container
-translates the protoobject into a similar protoobject without
-its autovivifying closure and puts that new protoobject into the
+Binding of an autovivifiable type object to a non-writeable container
+translates the type object into a similar type object without
+its autovivifying closure and puts that new type object into the
container instead (with any pertinent historical diagnostic information
carried over). There is therefore no magical method you can call on
-the readonly parameter that can magically autovivify the protoobject
+the readonly parameter that can magically autovivify the type object
after the binding. The newly bound variable merely appears to be a
-simple uninitialized value. (The original protoobject retains its
+simple uninitialized value. (The original type object retains its
closure in case it is rebound elsewhere to a read-write container.)
Some implementation notes: Nested autovivifications work by making
-nested protoobjects that depend on each other. In the general case
-the containers must produce protoobjects any time they do not know
+nested type objects that depend on each other. In the general case
+the containers must produce type objects any time they do not know
how the container will be bound. This includes when interpolated into
any capture that has delayed binding:
Modified: docs/Perl6/Spec/S10-packages.pod
===================================================================
--- docs/Perl6/Spec/S10-packages.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S10-packages.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -13,7 +13,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 27 Oct 2004
Last Modified: 13 Feb 2009
- Number: 10
Version: 9
=head1 Overview
Modified: docs/Perl6/Spec/S11-modules.pod
===================================================================
--- docs/Perl6/Spec/S11-modules.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S11-modules.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -13,7 +13,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 27 Oct 2004
Last Modified: 26 Mar 2009
- Number: 11
Version: 27
=head1 Overview
Modified: docs/Perl6/Spec/S12-objects.pod
===================================================================
--- docs/Perl6/Spec/S12-objects.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S12-objects.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -12,9 +12,8 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 27 Oct 2004
- Last Modified: 27 Apr 2009
- Number: 12
- Version: 80
+ Last Modified: 30 Apr 2009
+ Version: 81
=head1 Overview
@@ -120,15 +119,20 @@
...
}
-Every object (including any class object) delegates to an instance of
+Every object (including any class-based object) delegates to an instance of
its metaclass. You can get at the metaclass of any object via the
C<HOW> method, which returns an instance of the metaclass. A "class" object
is just considered an "empty"
-instance in Perl 6, more properly called a "prototype" object, or just
-"protoobject".
-The actual class object is the metaclass object pointed to by the
+instance in Perl 6, more properly called a "prototype" or "generic" object, or
just
+"type object". Perl 6 doesn't really have any classes named C<Class>.
+Types of all kinds are instead named via these undefined type objects,
+which are considered to have exactly the same type as an instantiated
+version of themsleves. But such type objects are inert, and do not
+manage the state of class instances.
+
+The actual object that manages instances is the metaclass object pointed to by
the
C<HOW> syntax. So when you say "C<Dog>", you're referring to both a
-package and a protoobject, that latter of which points to the
-actual object representing the class via C<HOW>. The protoobject
+package and a type object, the latter of which points to the
+object representing the class via C<HOW>. The type object
differs from an instance object not by having a different
type but rather in the extent to which it is defined. Some objects
may tell you that they are defined, while others may tell you that
@@ -496,7 +500,7 @@
Other OO languages give you the ability to declare "class" methods that either
don't
need or actively prohibit calls on instances. Perl 6 gives you a choice.
If you declare an ordinary method, it can function as a "class" method when you
-pass it a protoobject such as "C<Dog>" regardless of how defined the prototype
+pass it a type object such as "C<Dog>" regardless of how defined the prototype
object is, as long as the method body doesn't try to access any information
that
is undefined in the current instance.
@@ -683,11 +687,11 @@
In addition to the candidate position argument, C<bless> also
allows one or more positional arguments representing autovivifying
-protoobjects. Such an object looks like a prototype followed by a
+type objects. Such an object looks like a type name followed by a
hash subscript (see "Autovivifying objects" below). These are used
to initialize superclasses.
-Other than the candidate object and any autovivifying protoobjects,
+Other than the candidate object and any autovivifying type objects,
all arguments to C<bless> must be named arguments, not positional.
Hence, the main purpose of custom constructors is to turn positional
arguments into named arguments for C<bless>. The C<bless> method
@@ -717,17 +721,17 @@
modify the default behavior. The C<bless> function automatically
passes the appropriate argument list to the C<BUILD> of its various
parent classes. If the type of the parent class corresponds to one
-of the protoobjects passed to bless, that protoobject's argument
+of the type objects passed to bless, that type object's argument
list is used. Otherwise all the arguments to bless are passed to
the parent class's C<BUILD>. For the final C<BUILD> of the current
object, all the arguments to C<bless> are passed to the C<BUILD>, so
-it can deal with any protoobjects that need special handling. (It is
-allowed to pass protoobjects that don't correspond to any parent class.)
+it can deal with any type objects that need special handling. (It is
+allowed to pass type objects that don't correspond to any parent class.)
class Dog is Animal {...}
my $pet = Dog.new( :name<Fido>, Animal{ :blood<warm>, :legs(4) } );
-Here we are using an autovivifying C<Animal> protoobject to specify what
+Here we are using an autovivifying C<Animal> type object to specify what
the arguments to C<Animal>'s C<BUILD> routine should look like. (It does
not actually autovivify an C<Animal> apart from the one being created.)
@@ -1610,7 +1614,7 @@
Like type names, enum names are parsed as standalone tokens
representing scalar values, and don't look for any arguments.
-Unlike type names which are undefined protoobjects, enums are defined
+Unlike type names which are undefined type objects, enums are defined
constant values. Also unlike types, they do not respond to C<.()>
unless you mix in C<Callable> somehow.
They may not be post-declared.
@@ -1627,7 +1631,7 @@
is "poisoned".)
Enum types (and perhaps certain other finite, enumerable types such
-as finite ranges) define a C<.pick> method on the protoobject of
+as finite ranges) define a C<.pick> method on the type object of
that type. Hence:
my enum CoinFace <Heads Tails>;
@@ -1728,7 +1732,7 @@
Metamethods for objects are named with interrogative pronouns in uppercase:
- WHAT the protoobject of the type, stringifies to short name ~ '()'
+ WHAT the type object of the type, stringifies to short name ~ '()'
WHICH the object's identity value
WHO the package supporting the object, stringifies to long name
WHERE the memory address of the object
@@ -1761,8 +1765,8 @@
as the first argument to methods of the metaclass, while the other
forms require you to pass this explicitly.
-Note that WHAT appends C<()> to indicate emptiness. Use C<.perl> to get the
-bare name from a protoobject.
+Note that C<WHAT> appends C<()> to indicate emptiness. Use C<.perl> to get the
+bare name from a type object.
In general, use of these in ordinary code should be a red flag that
Something Very Strange is going on. (Hence the allcaps.) Most code
@@ -1929,7 +1933,7 @@
Whether this succeeds or not depends on whether the role is
sufficiently complete to serve as a class on its own. Regardless of
whether such an attempt would succeed, it is always perfectly fine to
-define a lazy protoobject for a role just as long as it's only ever
+define a lazy type object for a role just as long as it's only ever
used as an argument to C<bless>, since C<bless> will only be using
its closure to construct the role's C<BUILD> arguments in the context
of the complete new class. (Of course, an inconsistent or incomplete
@@ -1938,11 +1942,11 @@
failing at the point of class composition.)
Note that when used as an argument to a method like C<bless>,
-the protoobject is sufficiently lazy that autovivifying is done
+the type object is sufficiently lazy that autovivifying is done
only by the appropriate C<BUILD> routine. It does not waste energy
creating a C<Dog> object when that object's attributes would later
have to be copied into the actual object. (On top of which, such
-an implementation would make it impossible to use protoobjects to
+an implementation would make it impossible to use type objects to
initialize incomplete roles.)
The object autovivification syntax works only for literal named types,
Modified: docs/Perl6/Spec/S13-overloading.pod
===================================================================
--- docs/Perl6/Spec/S13-overloading.pod 2009-04-30 21:41:02 UTC (rev 26590)
+++ docs/Perl6/Spec/S13-overloading.pod 2009-04-30 22:37:09 UTC (rev 26591)
@@ -13,7 +13,6 @@
Maintainer: Larry Wall <la...@wall.org>
Date: 2 Nov 2004
Last Modified: 27 Dec 2008
- Number: 13
Version: 12
=head1 Overview
Modified: docs/Perl6/Spec/S14-roles-and-parametric-types.pod
===================================================================
--- docs/Perl6/Spec/S14-roles-and-parametric-types.pod 2009-04-30 21:41:02 UTC
(rev 26590)
+++ docs/Perl6/Spec/S14-roles-and-parametric-types.pod 2009-04-30 22:37:09 UTC
(rev 26591)
@@ -12,7 +12,6 @@
Jonathan Worthington <jn...@jnthn.net>
Date: 24 Feb 2009, extracted from S12-objects.pod
Last Modified: 30 Apr 2009
- Number: 14
Version: 3
=head1 Overview
Modified: docs/Perl6/Spec/S22-package-format.pod
===================================================================
--- docs/Perl6/Spec/S22-package-format.pod 2009-04-30 21:41:02 UTC (rev
26590)
+++ docs/Perl6/Spec/S22-package-format.pod 2009-04-30 22:37:09 UTC (rev
26591)
@@ -16,7 +16,6 @@
Maintainer: Jos Boumans <k...@cpan.org>
Date: 3 Nov 2005
Last Modified: 19 Dec 2008
- Number: 22
Version: 2
=head1 OVERVIEW
Modified: docs/Perl6/Spec/S32-setting-library/Basics.pod
===================================================================
--- docs/Perl6/Spec/S32-setting-library/Basics.pod 2009-04-30 21:41:02 UTC
(rev 26590)
+++ docs/Perl6/Spec/S32-setting-library/Basics.pod 2009-04-30 22:37:09 UTC
(rev 26591)
@@ -15,8 +15,8 @@
Moritz Lenz <mor...@faui2k3.org>
Tim Nelson <wayl...@wayland.id.au>
Date: 19 Mar 2009 extracted from S29-functions.pod
- Last Modified: 19 Feb 2009
- Version: 1
+ Last Modified: 30 Apr 2009
+ Version: 2
The document is a draft.
@@ -83,10 +83,10 @@
XXX Copied from S02 -- should it be deleted from there?
-The definition of C<.true> for the most ancestral type (that is, the
-C<Object> type) is equivalent to C<.defined>. Since protoobjects are
-considered undefined, all protoobjects (including C<Object> itself)
-are false unless the type overrides the definition of C<.true>
+The definition of C<.Bool> for the most ancestral type (that is, the
+C<Object> type) is equivalent to C<.defined>. Since type objects are
+considered undefined, all type objects (including C<Object> itself)
+are false unless the type overrides the definition of C<.Bool>
to include undefined values. Instantiated objects default to true
unless the class overrides the definition. Note that if you could
instantiate an C<Object> it would be considered defined, and thus true.
