r28196 - docs/Perl6/Spec
Author: moritz
Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
New Revision: 28196
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] spec behaviour of stubbed classes
This is a bit more general than what I had in mind first. If the implementors
say this is too hard to do it this way, we can degrade it to allow only a single
'...' term in the body of a stubbed class.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-09-06 15:06:11 UTC (rev 28195)
+++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 06:48:34 UTC (rev 28196)
@@ -55,6 +55,22 @@
class is also a module, it also handles any module-oriented keywords.
You can export subs from a class at use time, for instance.)
+If the class body throws an exception from a literal C... (yada) term,
+the class defintion is considered incomplete, and a second definition of
+that class does not complain, so you can write
+
+class Foo {
+has $!some_attr;
+
+... # literal ... here interrrupts class definition
+}
+
+# other code here
+
+class Foo {
+# rest of class defintion here
+}
+
A named class declaration can occur as part of an expression, just like
named subroutine declarations.
Re: r28196 - docs/Perl6/Spec
This spec subtly alters the meaning of Whereas yada used to
mean this is not yet implemented, complain if executed it now adds
but don't complain if it is a class fully implemented elsewhere.
Allowing two implementations of a class iff one of them has a yada
opens up maintenance issues. There's action at a distance, when
reading the source looking for the definition of class Foo- the
reader could be looking at one and not seeing the other. Editors and
code refactoring gets more complicated. It's too easy for two people
to edit the different class Foos without realizing there are two,
especially if they leave the yada in place in anticipation of
further editing reviewing.
Also this spec leaves some cases unspecc'ed. Does it matter which
order the yada class and complete class are compiled, or if there
are many yada classes? Do any of the definitions in the yada class
carry over into the complete class?
Does the same rule hold for methods, subs, all other named blocks, so
we can put a yada in one to pseudo-comment it out?
-y
On Sun, Sep 6, 2009 at 11:48 PM, pugs-comm...@feather.perl6.nl wrote:
Author: moritz
Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
New Revision: 28196
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] spec behaviour of stubbed classes
This is a bit more general than what I had in mind first. If the implementors
say this is too hard to do it this way, we can degrade it to allow only a
single
'...' term in the body of a stubbed class.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-09-06 15:06:11 UTC (rev 28195)
+++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 06:48:34 UTC (rev 28196)
@@ -55,6 +55,22 @@
class is also a module, it also handles any module-oriented keywords.
You can export subs from a class at use time, for instance.)
+If the class body throws an exception from a literal C... (yada) term,
+the class defintion is considered incomplete, and a second definition of
+that class does not complain, so you can write
+
+ class Foo {
+ has $!some_attr;
+
+ ... # literal ... here interrrupts class definition
+ }
+
+ # other code here
+
+ class Foo {
+ # rest of class defintion here
+ }
+
A named class declaration can occur as part of an expression, just like
named subroutine declarations.
Re: r28196 - docs/Perl6/Spec
I just saw the intent for this in the split up compilation of the
setting thread- that it is useful to:
Enable a class stub syntax that allows us to declare a given symbol
as being a valid class without having to declare the body of the
class at that time. For example:
class Rat { ... };
I can agree with that so long as the yada is the only token inside
the brackets. On the other hand why not go along with C convention and
allow
class Rat;
to pre-declare a class, or p5 convention
use class 'Rat';
-y
On Mon, Sep 7, 2009 at 9:44 AM, yarynot@gmail.com wrote:
This spec subtly alters the meaning of Whereas yada used to
mean this is not yet implemented, complain if executed it now adds
but don't complain if it is a class fully implemented elsewhere.
Allowing two implementations of a class iff one of them has a yada
opens up maintenance issues. There's action at a distance, when
reading the source looking for the definition of class Foo- the
reader could be looking at one and not seeing the other. Editors and
code refactoring gets more complicated. It's too easy for two people
to edit the different class Foos without realizing there are two,
especially if they leave the yada in place in anticipation of
further editing reviewing.
Also this spec leaves some cases unspecc'ed. Does it matter which
order the yada class and complete class are compiled, or if there
are many yada classes? Do any of the definitions in the yada class
carry over into the complete class?
Does the same rule hold for methods, subs, all other named blocks, so
we can put a yada in one to pseudo-comment it out?
-y
On Sun, Sep 6, 2009 at 11:48 PM, pugs-comm...@feather.perl6.nl wrote:
Author: moritz
Date: 2009-09-07 08:48:34 +0200 (Mon, 07 Sep 2009)
New Revision: 28196
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] spec behaviour of stubbed classes
This is a bit more general than what I had in mind first. If the implementors
say this is too hard to do it this way, we can degrade it to allow only a
single
'...' term in the body of a stubbed class.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-09-06 15:06:11 UTC (rev 28195)
+++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 06:48:34 UTC (rev 28196)
@@ -55,6 +55,22 @@
class is also a module, it also handles any module-oriented keywords.
You can export subs from a class at use time, for instance.)
+If the class body throws an exception from a literal C... (yada) term,
+the class defintion is considered incomplete, and a second definition of
+that class does not complain, so you can write
+
+ class Foo {
+ has $!some_attr;
+
+ ... # literal ... here interrrupts class definition
+ }
+
+ # other code here
+
+ class Foo {
+ # rest of class defintion here
+ }
+
A named class declaration can occur as part of an expression, just like
named subroutine declarations.
Re: r28196 - docs/Perl6/Spec
On Mon, Sep 07, 2009 at 09:56:51AM -0700, yary wrote:
I just saw the intent for this in the split up compilation of the
setting thread- that it is useful to:
Enable a class stub syntax that allows us to declare a given symbol
as being a valid class without having to declare the body of the
class at that time. For example:
class Rat { ... };
I can agree with that so long as the yada is the only token inside
the brackets. On the other hand why not go along with C convention and
allow
class Rat;
We can't use this one -- it already means something different
(namely, that the rest of the file is the specification for class Rat).
Pm
r28197 - docs/Perl6/Spec
Author: moritz
Date: 2009-09-07 19:30:17 +0200 (Mon, 07 Sep 2009)
New Revision: 28197
Modified:
docs/Perl6/Spec/S12-objects.pod
Log:
[S12] undo '...' semantics in class bodies.
Now only a single ... term in the classes marks that class as a forward
declaration, making it a declaration.
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-09-07 06:48:34 UTC (rev 28196)
+++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 17:30:17 UTC (rev 28197)
@@ -55,22 +55,10 @@
class is also a module, it also handles any module-oriented keywords.
You can export subs from a class at use time, for instance.)
-If the class body throws an exception from a literal C... (yada) term,
-the class defintion is considered incomplete, and a second definition of
-that class does not complain, so you can write
+If the class body consists only of a literal C... (yada) term, it is
+interpreted as a forward declaration that just tells the compiler that the
+class name is a type name, to be defined later on.
-class Foo {
-has $!some_attr;
-
-... # literal ... here interrrupts class definition
-}
-
-# other code here
-
-class Foo {
-# rest of class defintion here
-}
-
A named class declaration can occur as part of an expression, just like
named subroutine declarations.
Re: r28196 - docs/Perl6/Spec
yary wrote: [ a lot of good things that make lot of sense ] Your complaints and review by TimToady and pmichaud on #perl6 convinced me that this is not a good idea after all, see http://irclog.perlgeek.de/perl6/2009-09-07#i_1475421 Cheers, Moritz
r28199 - docs/Perl6/Spec
Author: lwall
Date: 2009-09-07 19:53:06 +0200 (Mon, 07 Sep 2009)
New Revision: 28199
Modified:
docs/Perl6/Spec/S04-control.pod
docs/Perl6/Spec/S10-packages.pod
docs/Perl6/Spec/S12-objects.pod
Log:
[S10] specify time of execution of package blocks and module (non)mainline code
[S12] give example of use of yada classes
Modified: docs/Perl6/Spec/S04-control.pod
===
--- docs/Perl6/Spec/S04-control.pod 2009-09-07 17:43:11 UTC (rev 28198)
+++ docs/Perl6/Spec/S04-control.pod 2009-09-07 17:53:06 UTC (rev 28199)
@@ -823,7 +823,7 @@
sets the topic in its signature can be broken out of. At run time,
Cbreak uses a control exception to scan up the dynamic chain to
find the activation record belonging to that same outer block, and
-when it has found that scope, it does a C.leave on it to unwinde
+when it has found that scope, it does a C.leave on it to unwind
the contexts. If any arguments are supplied to the Cbreak function,
they are passed out via the Cleave method. Since leaving a block is
considered a successful return, breaking out of one is also considered
Modified: docs/Perl6/Spec/S10-packages.pod
===
--- docs/Perl6/Spec/S10-packages.pod2009-09-07 17:43:11 UTC (rev 28198)
+++ docs/Perl6/Spec/S10-packages.pod2009-09-07 17:53:06 UTC (rev 28199)
@@ -13,8 +13,8 @@
Created: 27 Oct 2004
-Last Modified: 13 Feb 2009
-Version: 9
+Last Modified: 7 Sep 2009
+Version: 10
=head1 Overview
@@ -85,6 +85,44 @@
syntax that lets you do a lookup in a particular symbol table. In this case,
the key is not parsed for C::. It's just a hash lookup.
+All package bodies (including module and class bodies) execute at the
+normal execution time of the code in which they are embedded. For normal
+mainline code, this is the normal flow of execution; if this is too late
+to initialize something in the package that you want to be initialized,
consider
+use of a MAIN subroutine, which is invoked at the end of normal execution.
+See LS06/Declaring a CMAIN subroutine.
+
+For packages (modules, classes, roles, etc.) defined in separate files
+from the mainline code, there can be no mainline code by definition,
+but the top-level code in the used module needs to be executed at
+some point in case things need initialization. Invocation of this
+pseudo-mainline code in the module notionally happens no later than at
+the point of the Cuse or Cneed call in the process of compilation,
+but the module's code is assumed to be sufficiently uninteresting that
+it need be executed only once regardless of how many times the module
+is used subsequently in the compilation. (In fact, it might not need
+to run at all if the result of some previous compilation's run has
+been cached.)
+
+If it is desired to have code that varies in meaning from run to run,
+then you should put such code into an INIT block. (Likewise, you
+could put code into a CHECK block that has inconsistent semantics
+from compilation to compilation, but that's probably a bad idea.)
+
+In any case, it is erroneous for any external module to depend
+on any knowledge of its user with respect to compilation order or
+other contextual information, since other users may also depend on
+this single first-use execution and expect consistent semantics.
+(Really, all such contextual dependencies should be passed in at run
+time to the routines or methods of your module as normal parameters or
+contextual variables. For instance, you cannot know at module compile
+time whether your caller is going to be using 'fatal' semantics or not.
+That is dynamically scoped info.)
+
+If you wish to have a module that does something extra if invoked
+standalone, define a MAIN subroutine, which will be ignored if
+the module is merely used/needed elsewhere.
+
=head1 Package nesting
A declaration of any object of the form CA::B::c also creates (if needed)
Modified: docs/Perl6/Spec/S12-objects.pod
===
--- docs/Perl6/Spec/S12-objects.pod 2009-09-07 17:43:11 UTC (rev 28198)
+++ docs/Perl6/Spec/S12-objects.pod 2009-09-07 17:53:06 UTC (rev 28199)
@@ -13,8 +13,8 @@
Created: 27 Oct 2004
-Last Modified: 29 Jun 2009
-Version: 86
+Last Modified: 7 Sep 2009
+Version: 87
=head1 Overview
@@ -42,23 +42,43 @@
There are two basic class declaration syntaxes:
class Foo; # rest of file is class definition
-...
+has $.foo;
-class Bar {...} # block is class definition
+class Bar { has $.bar } # block is class definition
The first form is allowed only as the first declaration in a compilation
unit (that is, file or eval string).
-In either case, the code represented by C... executes at compile
-time as the body of a method of the metaclass, which is responsible
-for interpreting the
r28201 - docs/Perl6/Spec
Author: lwall
Date: 2009-09-07 20:32:55 +0200 (Mon, 07 Sep 2009)
New Revision: 28201
Modified:
docs/Perl6/Spec/S06-routines.pod
Log:
[S06] remove the slightly non-sensical 'use GLOBAL' in favor of 'defines'
Modified: docs/Perl6/Spec/S06-routines.pod
===
--- docs/Perl6/Spec/S06-routines.pod2009-09-07 18:03:22 UTC (rev 28200)
+++ docs/Perl6/Spec/S06-routines.pod2009-09-07 18:32:55 UTC (rev 28201)
@@ -15,8 +15,8 @@
Created: 21 Mar 2003
-Last Modified: 31 Aug 2009
-Version: 113
+Last Modified: 7 Sep 2009
+Version: 114
This document summarizes Apocalypse 6, which covers subroutines and the
@@ -270,20 +270,27 @@
may be made directly visible by importation.
Global subroutines and variables are normally referred to by prefixing
-their identifiers with C* (short for CGLOBAL::).
+their identifiers with the C* twigil, to allow contextual overrides.
-$*next_id = 0;
+GLOBAL::$next_id = 0;
sub GLOBAL::saith($text) { print Yea verily, $text }
module A {
my $next_id = 2; # hides any global or package $next_id
*saith($next_id); # print the lexical $next_id;
-*saith($*next_id); # print the global $next_id;
+*saith($*next_id); # print the dynamic $next_id;
}
+To disallow contextual overrides, you must access the globals directly:
+
+GLOBAL::saith($GLOBAL::next_id);
+
+The fact that this is verbose is construed to be a feature. Alternately,
+you may play aliasing tricks like this:
+
module B {
-use GLOBAL $next_id;
-*saith($next_id);# Unambiguously the global $next_id
+GLOBAL defines saith $next_id;
+saith($next_id);# Unambiguously the global definitions
}
=head2 Dynamically scoped subroutines
@@ -2532,8 +2539,8 @@
require COMPILING $x $y $z;
-Note that you need to use the run-time C:= and Crequire forms, not C::=
-and Cuse, because the macro caller's compile-time is the macro's runtime.
+Note that you need to use the run-time Crequire form, not
+Cuse, because the macro caller's compile-time is the macro's runtime.
=head2 Splicing
program vs module (was Re: r28199 ...)
pugs-comm...@feather.perl6.nl wrote:
+All package bodies (including module and class bodies) execute at the
+normal execution time of the code in which they are embedded. For normal
+mainline code, this is the normal flow of execution; if this is too late
+to initialize something in the package that you want to be initialized,
consider
+use of a MAIN subroutine, which is invoked at the end of normal execution.
+See LS06/Declaring a CMAIN subroutine.
It is sounding like you are saying every Perl module can have its own MAIN
subroutine ...
Just to clarify, is there really no structural distinction between a Perl
program and a Perl module, such that you could have either a .pl or a .pm be the
main program?
For example, if I wanted to write Perl in a manner a bit more Java-like where
everything is in a class, and so I wrote a MyProgram.pm file containing
something like:
class MyProgram {
submethod MAIN {
...
}
submethod other_meth {
}
}
... then could someone just say perl MyProgram.pm and it would just DWIM?
I would find it attractive to be able to structure my main program file as a
class like this if I wanted to.
Currently when I write a Perl 5 program I essentially do just that already, and
my main.pl doesn't do anything except explicitly invoke MyProgram-main(); I
would rather in Perl 6 to not have to have that file wrapper.
Another reason I ask is that if, conceptually some day one might store a Perl 6
program in a database, maybe using a separate database for each module, and so
that say connecting to a database is semantically the same as use/require-ing a
module/library, that the database format for the main program can be entirely
the same as one for a used module, and so just as you say something like use
MyModule from database connect string, one could implicitly from the command
line or a command prompt just say the same thing but if a MAIN() was in MyModule
then it would run implicitly as a program. For the interest of being a bit more
dynamic, in such a situation I would expect that an analogy of Perl's require
would be used instead to bring in other modules, at runtime.
-- Darren Duncan
Re: S26 - The Next Generation
Raiph elucidated:
Hmm. I was thinking Pod would be parsed by a P6/PGE grammar, one that
could be relatively easily edited/extended to suit another context, because,
I thought, it could then be made available as a stock --doc subsystem that
all PCT based languages get more or less for free.
Sure, that might be possible. The problem is one of syntax. Pod, as currently
specified, defines two syntaxes for magic comments that define documentation.
The difficulty is that both those syntaxes might already be in use in
other languages (the /^ \h* \= ident/ syntax most certainly will be),
so you end up having to change the Pod parsing syntax on a per-language
basis. I can't really see that being very attractive to the implementors
of other languages, nor the inconsistency being very attractive to users
of those languages.
We need a way of referring to ambient code within Pod, without the
Podder having to write more code to get it.
I was thinking it would be possible to reference (compiler) variables
representing eg. the name and sig of a block being parsed, or a block
or declaration which has just been parsed, or which is just about to be
parsed, and that simply referencing these variables would be ok and
would save the need to create explicit named anchors.
Well, that certainly *is* possible in Pod, which will definitely have
access to any compile-time
Perl variables, including the following usually bits of information:
$?FILE Which file am I in?
$?LINE Which line am I at?
?ROUTINE Which routine am I in?
?BLOCK Which block am I in?
$?SCOPE Which lexical scope am I in?
$?PACKAGE Which package am I in?
$?MODULEWhich module am I in?
$?CLASS Which class am I in? (as variable)
$?ROLE Which role am I in? (as variable)
$?GRAMMAR Which grammar am I in?
But that's not necessarily enough. I can imagine many other pieces of code that
you might want both in the source and in the documentation, but which it would
not be easy to extract from the introspective variables. For example:
PRE
=alias precondition
{
$_ 0
}
or:
if ($?TESTING)
=alias example1
{
my $tree = TreeClass.new();
$tree.size() == 0 :okTrees start life empty;
$tree.insert(node value);
$tree.size() == 1 :okInsertion increases tree size;
}
Not to mention all of the clever uses I can't think of yet. ;-)
Damian
Re: S26 - The Next Generation
Jon Lang kept his promise:
I promised some further thoughts; here they are:
Much appreciated.
As written, declarator aliasing attaches the alias to a piece of code,
and draws both the name and the alias from that. What about using a
special case of the declarator block for this? That is:
class Database::Handle { #=alias
has IO $!handle; #=alias
my Bool method open ($filename) {...} #=alias
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
or:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
Definitely interesting ideas, especially the second one. My concern
would be that they compete
with the #= blocks which might also be needed on such declarations.
Regardless of what syntax you use for declarator aliasing, I'd also
recommend some sort of numbering scheme if you alias more than one
declarator of the same type in the same lexical scope:
It's definitely an issue I hadn't considered properly. However, I
think the correct
solution is not numbering (which is always fraught with problems when subsequent
maintenance adds an extra declarator in the middle), but rather naming. Like so:
=alias
class Database::Handle {
=alias
has IO $!handle;
=alias open
my Bool method open ($filename) {...}
=alias close
my Bool method close() {...}
=for para
Note that the Aopen method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute, while the Aclose
method closes that handle.
}
I know this looks redundant. But the whole point of logical names is you
don't have to change them when the physical name changes:
=alias
class Database::Handle {
=alias
has IO $!handle;
=alias open
my Bool method open_file ($filename) {...}
=alias close
my Bool method close_and_sync() {...}
=for para
Note that the Aopen method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute, while the Aclose
method closes that handle.
}
If you adopt the declarator block basis for declarator aliasing, you
could even let the documenter choose his own names:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=m1
my Bool method close () {...} #=m2
An unrelated possibility would be to allow empty A tags in a
declarator block, with 'A' being replaced with the name of the
declarator to which the block is attached:
These are both very useful ideas.
I'll ponder them carefully in preparation for the next revision.
Thanks, Jon!
Damian
Re: S26 - The Next Generation
Damian Conway wrote: Raiph elucidated: I was thinking it would be possible to reference (compiler) variables representing eg. the name and sig of a block being parsed, or a block or declaration which has just been parsed, or which is just about to be parsed, and that simply referencing these variables would be ok and would save the need to create explicit named anchors. Well, that certainly *is* possible in Pod, which will definitely have access to any compile-time Perl variables, including the following usually bits of information: $?FILE Which file am I in? $?LINE Which line am I at? ?ROUTINE Which routine am I in? ?BLOCK Which block am I in? $?SCOPE Which lexical scope am I in? $?PACKAGE Which package am I in? $?MODULE Which module am I in? $?CLASS Which class am I in? (as variable) $?ROLE Which role am I in? (as variable) $?GRAMMAR Which grammar am I in? Huh. Would you be able to do something like: =begin pod Welcome to $?FILE. ...and have it interpolate the file's name? Or would you need some special markup for this, such as: =begin pod Welcome to A$?FILE. Or would you have to alias the variable and then refer to it? -- Jonathan Dataweaver Lang
Re: S26 - The Next Generation
Damian Conway wrote:
Jon Lang kept his promise:
I promised some further thoughts; here they are:
Much appreciated.
You're welcome.
As written, declarator aliasing attaches the alias to a piece of code,
and draws both the name and the alias from that. What about using a
special case of the declarator block for this? That is:
class Database::Handle { #=alias
has IO $!handle; #=alias
my Bool method open ($filename) {...} #=alias
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
or:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=
=for para
Note that the Amethod method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute.
}
Definitely interesting ideas, especially the second one. My concern
would be that they compete
with the #= blocks which might also be needed on such declarations.
I don't think that there will be a problem. First, #= is easy enough
to distinguish from #=; I don't foresee any confusion. Second, your
existing rules for #= already allow for multiple such blocks to be
attached to one thing, with the rule being that you append the latter
ones to the former ones:
#= Class Foo
class Foo {
#= a sample class used to illustrate.
#= This particular class has nothing in it.
}
...results in the equivalent of:
=for pod
Class Foo
a sample class used to illustrate.
This particular class has nothing in it.
With the ability to attach multiple declarator blocks to a single
declarator, it should be trivial to replace any one of them with a
declarator alias:
#=
class Foo {
#= Class Foo
#= a sample class used to illustrate.
#= This particular class has nothing in it.
}
There _is_ a question about when the alias becomes available:
#= Class Aclass
class Foo {
#= a sample class used to illustrate.
#= This particular class has nothing in it.
#= Xthis assigns to the 'class' declarator alias.
Would Aclass in the first line become 'Foo', or would it be whatever
Aclass was before that line? My later suggestion of an empty A
mitigates this problem by making such references less frequent in
practice; but it doesn't eliminate it. My personal preference would
be for it to refer to 'Foo'; but that would involve postponing the
evaluation of Foo's WHY block until all possible relevant data has
been collected.
Regardless of what syntax you use for declarator aliasing, I'd also
recommend some sort of numbering scheme if you alias more than one
declarator of the same type in the same lexical scope:
It's definitely an issue I hadn't considered properly. However, I
think the correct
solution is not numbering (which is always fraught with problems when
subsequent
maintenance adds an extra declarator in the middle), but rather naming. Like
so:
I tend to agree. I only proposed numbering as a way of being able to
access different declarators without having to explicitly label them.
I can definitely understand if this option gets dropped as being too
error-prone with regard to maintenance.
=alias
class Database::Handle {
=alias
has IO $!handle;
=alias open
my Bool method open ($filename) {...}
=alias close
my Bool method close() {...}
=for para
Note that the Aopen method of class Aclass
stores the resulting low-level database handle
in its private Ahas attribute, while the Aclose
method closes that handle.
}
The problem with this example is that '=alias name' isn't a declarator
alias; it's a block alias. (I don't have a problem with the
underlying concept that you're trying to illustrate.) So Aopen
would be 'my Bool method open($filename) {...}', when what you'd be
looking for in a named declarator alias would be 'open'. (And it
might not even be that, unless you loosen the syntactic requirements
for a block alias: there are no subsequent curly braces to define how
much gets aliased.) Which brings me to:
If you adopt the declarator block basis for declarator aliasing, you
could even let the documenter choose his own names:
class Database::Handle { #=
has IO $!handle; #=
my Bool method open ($filename) {...} #=m1
my Bool method close () {...} #=m2
This would be a way to do a named declarator alias, for distinguishing
between multiple aliases to the same type of declarator.
Indeed, you might end up making extensive use of embedded named
declarator aliases (ENDAs? :P ), since as soon as you reach the
close-bracket, you have the rest of the line available for other uses
(such as declarator blocks):
class Database::Handle
