Re: Abstract roles, classes and objects
In a message dated Sun, 1 Oct 2006, Aaron Sherman writes:
Trey Harris wrote:
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
[snip]
However, that's not to say that a class can't be abstract, just that a
class that does an interface (a role with nothing but abstract methods)
must implement the role's interface.
So why would it generate an error? Why wouldn't it merely result in B
being abstract too, assuming that contra my prior mail, classes can be
abstract?
What use is an interface if it doesn't give you a guarantee? If I say, all
dogs can bark, and you define a dog that can't bark, that's not abstract,
that's a failure to meet the interface requirements of a dog.
No--I wouldn't define a dog that can't bark, I'd define a dog that *can*
bark, but I wouldn't say *how* it could bark (conjecturing an is
abstract class trait I give a sample implementation of below):
class Dog is abstract { method bark () { ... } #[ ... ] }
class Pug is Dog { method bark () { self.vocalize($.barkNoise) } }
my Dog $fido .= new; # exception, instantiating abstract class
my Dog $fido = Pug.new; # good, $fido can bark
Seems like there would be three ways to achieve the guarantee: an explicit
is abstract marker like above to prevent instantiation; some way to
infer concreteness (this gets into my earlier question of whether
yada-yada is enough to do so) so you can prevent instantiation; or simply
disallow abstract classes entirely.
It sounds like the assumption thus far has been that the existance of
roles imply that abstract classes are disallowed, so you'd write:
role Dog { method bark { ... } #[ ... ] }
class Pug does Dog { method bark { .vocalize($.barkNoise) } }
S12 says: Classes are primarily for instance management, not code reuse.
Consider using Croles when you simply want to factor out
common code.
But if I want to write code that handles the instance management for
several related classes but cannot be instantiated itself, that must be a
role and not a class. But instance management, as the S12 quote says, is
the purpose of classes, not roles. Is it a deep requirement of the
MOP/MRP that only one of classes and roles can be abstract?
I've looked at my uses of uninstantiable classes in Perl 5 for the past
few years, and I think that almost all of them could be done as roles
(though for some of them the cognitive dissonance of calling a set of
object-management methods a role still bothers me). But there's one
case where I can't figure out how to do it except for throwing a runtime
exception in a class.
For a system monitoring application, I have a class heirarchy like the
following (bare names indicate concrete instantiable classes, brackets
indicate uninstantiable abstract ones):
+ [SystemMonitor]
- CPUMonitor
- DiskMonitor
+ ScriptedMonitor
+ [HardwareMonitor]
- FanMonitor
- TempMonitor
- PowerSupplyMonitor
Here, SystemMonitor is abstract and sets up the data collection and
storage routines. Its concrete subclasses implement how to actually get
the data and any munging the data requires, but otherwise inherit their
behavior from SystemMonitor. ScriptedMonitor is a concrete class that
gets a script attribute which it runs and a closure attribute it uses to
munge the data the script generates.
Turns out that there are many HardwareMonitors that all run the same suite
of hardware monitoring scripts and performs the same munging on them, but
has almost the same behavior as ScriptedMonitor. So I handled that by
subclassing it with a new abstract class, HardwareMonitor, which factored
out the new behavior all the hardware monitors shared. I then subclassed
*that* with concrete classes implementing the last little unfactorable
bits. So Abstract - Concrete - Abstract - Concrete.
new(), for instance, was defined only in SystemMonitor (but threw an
exception if you tried to call it on SystemMonitor, thus making the class
abstract); gatherData() is called in SystemMonitor but is defined only in
the direct subclasses of SystemMonitor, and is overridden in
HardwareMonitor with a call to the superclass method
(ScriptedMonitor::gatherData). HardwareMonitor's subclasses just define
some munging methods that HardwareMonitor's processData() methods calls.
In this way, I never repeat myself, I use polymorphism so that I never
write any conditionals involving the type of anything (except in the case
of new() throwing an exception to prevent instantiation of an abstract
class), and related code goes together. This is a good thing.
In Perl 6, the abstract SystemMonitor could be a role, and a concrete
ScriptedMonitor could be a class that does SystemMonitor, but it's not at
all clear to me what HardwareMonitor would be, since classes can't be
abstract and roles can't inherit from classes. I guess it would be a
role, but then we'd have something like:
- role
Re: Don't tell me what I can't do!
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: Would there be such tools used in the core libraries? Maybe, maybe not, we could discuss that. If they were implemented in the core libraries would there be a universal no bondage flag that shut them off? Probably, since that's something that Perl tends to like doing. The assumption I remember from the design meetings was always No library designer has the knowledge or the right to tell me how fast or strict my program has to run. Whatever BD you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. In my opinion,Perl 6 should spell no bondage: #!/usr/bin/perl6 -- c
Re: Nested statement modifiers.
On 10/3/06, Aaron Sherman [EMAIL PROTECTED] wrote: Paul Seamons wrote: It relates to some old problems in the early part of the RFC/Apocalypse process, and the fact that: say $_ for 1..10 for 1..10 Was ambiguous. The bottom line was that you needed to define your parameter name for that to work, and defining a parameter name on a modifier means that you have to parse the expression without knowing what the parameters are, which is ugly in a very non-stylistic sense. I don't think that is ambiguous though. It really is, and the very first question that everyone asks is: how do I get access to the outer loop variable, which of course, you cannot for the reasons stated above. What about $OUTER::_ ? Shouldn't that access the outer $_ ? Let's get P6 out the door, and then discuss what tiny details like this do or don't make sense. -- Markus Laire
Re: Nested statement modifiers.
Damian Conway skribis 2006-10-03 16:40 (-0700):
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Oh. For some reason, I thought this exception was for loops only.
--
korajn salutojn,
juerd waalboer: perl hacker [EMAIL PROTECTED] http://juerd.nl/sig
convolution: ict solutions and consultancy [EMAIL PROTECTED]
Re: Don't tell me what I can't do!
In a message dated Wed, 4 Oct 2006, chromatic writes: The assumption I remember from the design meetings was always No library designer has the knowledge or the right to tell me how fast or strict my program has to run. Whatever BD you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. Yes, but by the same token, no library designer should force you to be *less* strict than you wish to. I remember not so many years ago when there were a lot of modules floating around that required you to do no strict of various flavors in order to use them. I still run across modules that need no warnings. (I won't name names, because some of their authors post to this list ;) It should at the very least be *possible* to write modules that can be used in every level of strictness from one-liners to every-possible-stricture, everything-typed, everything-contracted systems. If it's fairly easy to do, so much the better--there's a better chance that you won't have to fork somebody else's module to get it to work with the level of BD you want. As for the core--in DBC, which is what started this thread in the first place, the compiler and runtime do various correctness inferences based on contracts. If you call some code that doesn't have a contract, you can either blow up, or you can just assert that the code you're calling is correct--at which point you can no longer guarantee your own contract. It's not a stricture that can be lexically toggled off and on like a pragma. So if Perl 6 is going to support DBC, the core needs to support DBC too. Nobody is forcing you to use DBC in order to use the core modules, though. In fact, most DBC systems I'm aware of run in production with contract-checking turned off; the checks are for testing and debugging. So even DBC programs themselves have to be able to run at a lower level of strictness. In my opinion,Perl 6 should spell no bondage: #!/usr/bin/perl6 No, it should spell no more, or less, bondage than you want. Trey
Re: Nested statement modifiers.
On 10/4/06, Juerd [EMAIL PROTECTED] wrote:
Damian Conway skribis 2006-10-03 16:40 (-0700):
Which can also be written as:
do { do { say 1 if 1 } if 1 } if 1;
Sorry, no it can't. From S4
(http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
Unlike in Perl 5, applying a statement modifier to a do block is
specifically disallowed
Oh. For some reason, I thought this exception was for loops only.
According to S04 Cdo { ... } is a loop, The do-once loop.
--
Markus Laire
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 12:50:16AM -0700, chromatic wrote: On Tuesday 03 October 2006 10:06, Aaron Sherman wrote: Would there be such tools used in the core libraries? Maybe, maybe not, we could discuss that. If they were implemented in the core libraries would there be a universal no bondage flag that shut them off? Probably, since that's something that Perl tends to like doing. The assumption I remember from the design meetings was always No library designer has the knowledge or the right to tell me how fast or strict my program has to run. Whatever BD you do in the privacy of your own modules is fine, but if it leaks out past encapsulation boundaries, expect that somewhere you might offend community standards. That's really a pity. I'd very much like the rope to be able to build 'strict::with::pride' like toolsto say nothing of being able to build my own private 'taint'. One of the things that many shops have defected from Perl to Java for is the additional handcuffs that Java provides for less-than-experienced developers. Giving me the power to control what my team, or folks using my language variant, do could be a huge win. But hey, if you don't want to use those libraries, that's cool. -j
Re: Nested statement modifiers.
It may be more useful to discuss this issue using less contrived examples. :) I would agree. I haven't had any use for a double if or a double for. The double if case is handled by . The double for case is handled by for and map. The interesting cases are combinations of if and for and while and unless. .say if cond($_) for =; That one is sort of not necessary now that grep can be lazy. .say for = if $read_the_rest; Which can obviously be written in other ways using other constructs, but not without changing how the statement reads or changing what it emphasizes. And as for Perl6 - well yes I'd love to see it get here more quickly also. But I don't think that discussing little nitpicks like this are delaying the release of Perl6. Maybe they are - but I would guess there are more pressing issues that are occupying development time. Paul
Exceptions on hypers
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { die if $i++ 5 } }
my Array of A @aoa;
try { @aoa.inci; }
say $i;
Is it even possible to know, or is it entirely dependent on the
implementation? And what do multiple, successive dies within the same
try block do?
Re: Exceptions on hypers
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there were supposed to be 10 elements):
my $i = 0;
class A { method inci() { die if $i++ 5 } }
my @aoa = map {A.new} 1..10;
try { @aoa.inci; }
say $i;
We now return you to your regularly scheduled question, already in progress:
Is it even possible to know, or is it entirely dependent on the
implementation? And what do multiple, successive dies within the same
try block do?
Abstract roles, classes and objects
Trey Harris wrote:
It sounds like the assumption thus far has been that the existance of
roles imply that abstract classes are disallowed, so you'd write:
role Dog { method bark { ... } #[ ... ] }
class Pug does Dog { method bark { .vocalize($.barkNoise) } }
S12 says: Classes are primarily for instance management, not code reuse.
Consider using Croles when you simply want to factor out
common code.
To me, instance management means the package can create, build, and
destroy objects - not the package initializes and cleans up
attributes. A 'class' that is forbidden from creating, building, and
destroying objects isn't a class; it's a role. In fact, you can think
of 'role' as being shorthand for 'abstract class' - after all, the
only difference between a concrete class and an abstract class is that
the former must implement everything and can manage instances, while
the latter cannot manage instances but doesn't have to implement
everything.
-snip-
In Perl 6, the abstract SystemMonitor could be a role, and a concrete
ScriptedMonitor could be a class that does SystemMonitor, but it's not at
all clear to me what HardwareMonitor would be, since classes can't be
abstract and roles can't inherit from classes.
S12 says:
* A role is allowed to declare an additional inheritance for its
* class when that is considered an implementation detail:
*
* role Pet {
* is Friend;
* }
So:
role SystemMonitor { ... }
class CPUMonitor does SystemMonitor { ... }
class DiskMonitor does SystemMonitor { ... }
class ScriptedMonitor does SystemMonitor { ... }
role HardwareMonitor is ScriptedMonitor { ... }
class FanMonitor does HardwareMonitor { ... }
class TempMonitor does HardwareMonitor { ... }
class PowerSupplyMonitor does HardwareMonitor { ... }
# and so on
is perfectly valid, and is shorthand for
role SystemMonitor { ... }
role HardwareMonitor { ... }
class CPUMonitor does SystemMonitor { ... }
class DiskMonitor does SystemMonitor { ... }
class ScriptedMonitor does SystemMonitor { ... }
class FanMonitor is ScriptedMonitor does HardwareMonitor { ... }
class TempMonitor is ScriptedMonitor does HardwareMonitor { ... }
class PowerSupplyMonitor is ScriptedMonitor does HardwareMonitor { ... }
# and so on
ISTR that it's also possible to treat a class as if it were a role
(e.g., does classname is valid, both as a statement in another role
or class and as an expression used to test the truth of the claim),
although I can't seem to find documentation for this at the moment.
--
Jonathan Dataweaver Lang
Re: Exceptions on hypers
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
:@bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what will $i be:
:
: my $i = 0;
: class A { method inci() { die if $i++ 5 } }
: my Array of A @aoa;
: try { @aoa.inci; }
: say $i;
:
: Is it even possible to know, or is it entirely dependent on the
: implementation? And what do multiple, successive dies within the same
: try block do?
An uncaught exception is going to blow you out of the hyperoperator
when it's partway done, just like any other operator. Since a
hyperoperator is a promise that you don't care about ordering of side
effects, any code that relies on a particular implementation's ordering
of side effects is erroneous.
Which is all an excellent argument for unthrown exceptions being
the norm. Then the hyper can proceed to completion and you just
have to be careful how you use the resulting undefined values.
For hypers that must produce unboxed native types, you don't have
the undef option, but at least IEEE floaters give you NaN and Inf.
This also tells me that we'll occasionally want to turn normally fatal
exceptions into unthrown exceptions. Fortunately, Perl 6 specifies
that CATCH blocks run before the stack is unwound, so this should be
possible in theory. Of course, this is not guaranteed to work unless
the undef value is returned immediately to the hyperoperator manager,
since the called code may not have anticipated that it might have to
continue with an undefined value.
All the more reason to encourage use of fail rather than die.
Larry
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 01:05, jesse wrote: One of the things that many shops have defected from Perl to Java for is the additional handcuffs that Java provides for less-than-experienced developers. Giving me the power to control what my team, or folks using my language variant, do could be a huge win. The point is that the person writing the program decides which handcuffs or costumes all of the code has to wear, not the person writing the libraries. If you want to set a policy for your organization, that's fine. It is just Not Okay for me or anyone to write a module right now that dictates exactly the strictness of every program written in the next twenty years that uses it. -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:09, jesse wrote: Perhaps I'm misunderstanding what you mean by person writing the program and person writing the libraries. In fact, I've _gotta_ be. I'd like to be able to put my strictures in a library rather than forcing them into the main body of a program. Are you saying you don't want to let people do this? Let me rephrase. Libraries and modules can be as strict or as lax as they like, but the program *using* those libraries and modules should always be able to override those strictures. If you write a class in a library and declare it as closed, that's fine -- but any program that uses the class should always have the option of saying Nope, not closed. I need to do something with it. It's the person *using* the libraries and modules and classes who knows how strict they need to be, how closed they need to be, and how optimized they need to be. If any of those policies are irreversible--if they leak out of libraries and modules and classes--then there is a problem. -- c
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 12:48, jesse wrote: Ok. So, I think what you're saying is that it's not a matter of don't let people write libraries that add strictures to code that uses those modules but a matter of perl should always give you enough rope to turn off any stricture imposed on you by external code. Do I have that right? Yes. You might also add ... or enable further strictures, but that sounds like what I was trying to say. -- c
Re: Don't tell me what I can't do!
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote: On Wednesday 04 October 2006 01:05, jesse wrote: One of the things that many shops have defected from Perl to Java for is the additional handcuffs that Java provides for less-than-experienced developers. Giving me the power to control what my team, or folks using my language variant, do could be a huge win. The point is that the person writing the program decides which handcuffs or costumes all of the code has to wear, not the person writing the libraries. If you want to set a policy for your organization, that's fine. It is just Not Okay for me or anyone to write a module right now that dictates exactly the strictness of every program written in the next twenty years that uses it. So, you're in favor of Perl 6 not having a use strict;? Or are you in favor of there being only one true strict? Perhaps I'm misunderstanding what you mean by person writing the program and person writing the libraries. In fact, I've _gotta_ be. I'd like to be able to put my strictures in a library rather than forcing them into the main body of a program. Are you saying you don't want to let people do this? Jesse -- c --
Re: Don't tell me what I can't do!
In a message dated Wed, 4 Oct 2006, jesse writes: On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote: The point is that the person writing the program decides which handcuffs or costumes all of the code has to wear, not the person writing the libraries. If you want to set a policy for your organization, that's fine. It is just Not Okay for me or anyone to write a module right now that dictates exactly the strictness of every program written in the next twenty years that uses it. Perhaps I'm misunderstanding what you mean by person writing the program and person writing the libraries. In fact, I've _gotta_ be. I'd like to be able to put my strictures in a library rather than forcing them into the main body of a program. Are you saying you don't want to let people do this? I read it as yes, you *can* put strictures on the using code into a library, though I wouldn't do it and would say that any module that does so shouldn't be released on CPAN for general use. But even if you can do that, you *must* always be able to turn the strictures back off. chromatic, is that a fair paraphrase? I don't have any problem with that sentiment--if I were you and needed to enforce some style on other programmers who work with me, I'd just tell them to use my library and not unuse it. It's a human problem, not a technical one, if they insist on unusing it by nefarious means. That philosophy doesn't present any problems with DBC checks, which as I mentioned before probably have to handled as a program-global flag rather than as a lexical pragma anyway. (I'm toying with the notion of jurisdictions that packages could subscribe to across which a set of contracts would be enforceable, allowing them to do DBC while still using or being used by code out in some other lawless jurisdiction. Code that doesn't explicitly join some jurisdiction would by default be lawless, thus living by the philosophy chromatic's espousing. I think that could be made to work, though jurisdictions would have to be at a package, not scope, level. I need to think about it more, though.) Trey
Re: Don't tell me what I can't do!
On Wednesday 04 October 2006 13:25, Trey Harris wrote: I read it as yes, you *can* put strictures on the using code into a library, though I wouldn't do it and would say that any module that does so shouldn't be released on CPAN for general use. But even if you can do that, you *must* always be able to turn the strictures back off. chromatic, is that a fair paraphrase? Yes. I don't have any problem with that sentiment--if I were you and needed to enforce some style on other programmers who work with me, I'd just tell them to use my library and not unuse it. It's a human problem, not a technical one, if they insist on unusing it by nefarious means. Very much so. It seems silly to put up barriers such that clever people have to use ugly and hackish tricks to do clever things while attempting to use technology to solve the social problem of other people doing really bad things. If you violate my first law of software development (Don't hire monkeys!), then you should at least follow its corollary (Train your monkeys well and watch them very carefully. Note how unfulfilling your life is for violating the first law.). That philosophy doesn't present any problems with DBC checks, which as I mentioned before probably have to handled as a program-global flag rather than as a lexical pragma anyway. (I'm toying with the notion of jurisdictions that packages could subscribe to across which a set of contracts would be enforceable, allowing them to do DBC while still using or being used by code out in some other lawless jurisdiction. Code that doesn't explicitly join some jurisdiction would by default be lawless, thus living by the philosophy chromatic's espousing. I think that could be made to work, though jurisdictions would have to be at a package, not scope, level. I need to think about it more, though.) That sort of thing ought to be quite possible, but the less work we spend on giving people the illusion that this discipline is inescapable and perfectly capable, the more time we'll have to tell them how to avoid hiring monkeys, which actually fixes more problems in software development than anything else I've ever seen. -- c
Re: Abstract roles, classes and objects
In a message dated Wed, 4 Oct 2006, Jonathan Lang writes:
In Perl 6, the abstract SystemMonitor could be a role, and a concrete
ScriptedMonitor could be a class that does SystemMonitor, but it's not at
all clear to me what HardwareMonitor would be, since classes can't be
abstract and roles can't inherit from classes.
S12 says:
* A role is allowed to declare an additional inheritance for its
* class when that is considered an implementation detail:
*
* role Pet {
* is Friend;
* }
Thanks. This is what I was missing. I read the above, together with A
role may not inherit from a class, but may be composed of other roles, as
specifying that any class doing Pet must already be a Friend, not that
doing Pet caused you to inherit from Friend.
I now see that what it meant was a role may not *inherit* from a class,
because inheritance is a concept that only applies to instantiated
objects, but a role can *cause* its class to inherit from a class, which
works out to pretty much the same thing...
So long as .post_data would work on a TempMonitor object below:
role SystemMonitor {
method post_data ($value, :$units, :$timestamp) {
# complete implementation here
}
}
class ScriptedMonitor is SystemMonitor {
# post_data never mentioned
}
role HardwareMonitor is ScriptedMonitor {
method post_data { next METHOD }
}
class TempMonitor is HardwareMonitor {
method post_data ($value, *%_) { call($value, :units(Celsius), |%_) }
}
I'm happy. It sounds like it should.
Trey
Mailing list archive and index
I'm noodling around with the idea of creating an archive and index of all of the messages to the mailing list over the years for purposes of quickly finding all of the messages that have definitive information on a given topic. Simply searching on Google or through my mail spool just doesn't cut it, since there's too much discussion and too little decision (I'm not calling it signal-to-noise, since that's somewhat pejorative, and I'm not trying to say the discussion is useless, just not usually what I'm looking for). To that end, I've got a mockup of what I'm thinking of with a handful of Larry's messages in it (in Mediawiki): http://www.ajs.com/perl6index/index.php/Perl.perl6.language If people like it, then I'll write a tool that automatically populates the database, and the site will probably get its own hostname for future flexibility. Ultimately the categorization (which is the important part) will have to be a manual task, but it's not quite as daunting as one might think, given a MediaWiki that contains all of the messages. Any thoughts? Here are some other starting points if you like: Everything by Larry (currently everything): http://www.ajs.com/perl6index/index.php/Category:Larry_Wall Brainstorming: http://www.ajs.com/perl6index/index.php/Category:Brainstorming Last month: http://www.ajs.com/perl6index/index.php/Category:September_2006 One other way to go would be to take all of the summaries and start with those. Then, each message could be a link from a summary Then again, that could always be put in later, and finding the mapping between summaries and threads might be a pain, programmatically.
Re: Don't tell me what I can't do!
Trey Harris wrote: I read it as yes, you *can* put strictures on the using code into a library, though I wouldn't do it and would say that any module that does so shouldn't be released on CPAN for general use. ... Hey, I have an idea. Let's write a module that enforces that! Seriously, I think you're all getting way too wound up about this. No one is going to force you to eat your peas. ;)
[svn:perl6-synopsis] r12675 - doc/trunk/design/syn
Author: audreyt
Date: Wed Oct 4 21:16:26 2006
New Revision: 12675
Modified:
doc/trunk/design/syn/S12.pod
Log:
* S12: Remove the troublesome single-arg-function-become-method rule:
sub foo (*$x) { $x }
foo(want); # Always in list context, never evaluated as want.foo
As an alternative solution to the close $fh problem, specify that
class IO has a method close () is export that manufactures a multi
sub-into-method dispatcher.
The export-method semantics needs more detailed treatment in the spec,
but it's important to note that somesub $x and $x.somesub are no
longer interchangeable now.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(original)
+++ doc/trunk/design/syn/S12.podWed Oct 4 21:16:26 2006
@@ -14,7 +14,7 @@
Date: 27 Oct 2004
Last Modified: 20 Sept 2006
Number: 12
- Version: 27
+ Version: 28
=head1 Overview
@@ -196,18 +196,24 @@
Indirect object notation now requires a colon after the invocant if
there are any arguments. If there are no arguments and you omit the
colon, the notation is parsed either as a named unary operator or a
-list operator with one argument. In any case, all of these come out
-to the same thing:
+list operator with one argument.
+
+These two are considered method calls, which will fall back to a
+subroutine call if the method was not found:
$handle.close
-close($handle)
close $handle:
-close $handle
-To explicitly reject method call and only consider subs, put a
-trailing comma after the single positional argument:
+To reject method call and only consider subs, simply omit the colon
+from the invocation line:
-close($handle,)
+close($handle)
+close $handle
+
+However, here the built-in BIO class defines Cmethod close is export (),
+which puts a Cmulti sub close (IO) in scope by default. Thus if the
+C$handle evaluates to an IO object, then the two subroutine calls above
+are still translated into method calls.
Dot notation can omit the invocant if it's in C$_:
[svn:perl6-synopsis] r12678 - doc/trunk/design/syn
Author: larry Date: Wed Oct 4 21:23:57 2006 New Revision: 12678 Modified: doc/trunk/design/syn/S05.pod Log: y/// is dead. Modified: doc/trunk/design/syn/S05.pod == --- doc/trunk/design/syn/S05.pod(original) +++ doc/trunk/design/syn/S05.podWed Oct 4 21:23:57 2006 @@ -14,9 +14,9 @@ Maintainer: Patrick Michaud [EMAIL PROTECTED] and Larry Wall [EMAIL PROTECTED] Date: 24 Jun 2002 - Last Modified: 27 Sept 2006 + Last Modified: 4 Oct 2006 Number: 5 - Version: 34 + Version: 35 This document summarizes Apocalypse 5, which is about the new regex syntax. We now try to call them Iregex rather than regular @@ -2844,6 +2844,9 @@ $str.=trans( %mapping.pairs.sort ); +(Perl 6 does not support the Cy/// form, which was only in Csed because +they were running out of single letters.) + =item * The two sides of any pair can be strings interpreted as Ctr/// would:
[svn:perl6-synopsis] r12681 - doc/trunk/design/syn
Author: larry Date: Wed Oct 4 21:55:49 2006 New Revision: 12681 Modified: doc/trunk/design/syn/S12.pod Log: forgot date change. Modified: doc/trunk/design/syn/S12.pod == --- doc/trunk/design/syn/S12.pod(original) +++ doc/trunk/design/syn/S12.podWed Oct 4 21:55:49 2006 @@ -12,7 +12,7 @@ Maintainer: Larry Wall [EMAIL PROTECTED] Date: 27 Oct 2004 - Last Modified: 20 Sept 2006 + Last Modified: 4 Oct 2006 Number: 12 Version: 28
