> Please tell me there will be a way to work out if you're called as a
> subroutine or as a method.
Yes. Subroutines and methods will inhabit different namespaces
(modules and classes respectively):
module X;
sub s { print "I am the very model of a modern Perl 6 subroutine
Damian Conway <[EMAIL PROTECTED]> writes:
>
>> And package::subroutine should go the way of package`subroutine
> as
>
>> package.subroutine will work and become the preferred method :),
> no?
>
>
> Err...no. They're still not the same thing in Perl 6:
>
> package::subroutine(
> So a class method and a plain function call are still not the same
> thing?
Correct.
Damian
On Thu, 4 Oct 2001 14:33:54 +1000 (EST), Damian Conway wrote:
>To: [EMAIL PROTECTED]
>Subject: Re: A3, the ';' operator, and hyper-operators
>From: Damian Conway <[EMAIL PROTECTED]>
>Date: Thu, 4 Oct 2001 14:33:54 +1000 (EST)
>
>
> > And package:
On Fri, 5 Oct 2001 06:00:07 +1000 (EST), Damian Conway wrote:
> > $foo + $bar
> >
> > will call $foo's overloaded add if it has one no matter where $foo's used.
>
>Sorry. I should have been clearer.
>
>Dan is, of course, correct. Overloaded operators that are class methods
>will tag al
> At 02:18 PM 10/4/2001 +1000, Damian Conway wrote:
> >> ** Miscellaneous
> >>
> >> Why 'operator:+' instead of 'operator::+'? (Other than the
> >> potential verbosity required to declare operators within a
> >> particular package.) I would think it more int
On Thu, Oct 04, 2001 at 11:17:38AM -0400, John Siracusa wrote:
> Hmmm...does anyone else remember when the suggestion that '.' continue to be
> used as the concat operator in Perl 6 was shouted down because it would
> require space on either side of it? It seems to me that we've come full
> circl
AP3 says:
> So, instead of:
>
>$a . $b . $c
>
> you'll say:
>
>$a _ $b _ $c
>
> The only downside to that is the space between a variable name and
> the operator is required. This is to be construed as a feature.
On 10/4/01 12:18 AM, Damian Conway wrote:
>> sub _mysub {}
>> $a = _mysub;
>
At 02:18 PM 10/4/2001 +1000, Damian Conway wrote:
>> ** Miscellaneous
>>
>> Why 'operator:+' instead of 'operator::+'? (Other than the
>> potential verbosity required to declare operators within a
>> particular package.) I would think it more intuitive to think of
>> 'opera
On Wed, Oct 03, 2001 at 11:26:17PM -0500, Jonathan Scott Duff wrote:
> On Thu, Oct 04, 2001 at 01:24:13PM +1000, Damian Conway wrote:
> > >From E3:
> >
> > The doubling also helps it stand out better in code, in part
> > because it forces you to put space around the C<::> so that
> And package::subroutine should go the way of package`subroutine as
> package.subroutine will work and become the preferred method :), no?
Err...no. They're still not the same thing in Perl 6:
package::subroutine(@args) --> package::subroutine(@args)
package.subroutine
> So does that mean that the Perl5 meaning of
>
>@refs = \($a, $b, $c);
>
> will go away?
I doubt it.
> It seems like it should as it's a caretless hyper.
Not really. Or, at least, no more so than C or C or C is.
Hyperoperators apply to *arrays* not lists.
What w
On Thu, Oct 04, 2001 at 01:24:13PM +1000, Damian Conway wrote:
> >From E3:
>
> The doubling also helps it stand out better in code, in part
> because it forces you to put space around the C<::> so that it's
> not confused with a package name separator.
And package::subrou
On Thursday 04 October 2001 12:18 am, Damian Conway wrote:
>> ** Binary //
>>
>> Was a test for definedness *and* truthfulness considered?
>
> Err... the || operator *is* a test for that.
Hmmph. So it is. All those wasted keystrokes that I'll never recover...
how depressing.
--
B
On Thu, Oct 04, 2001 at 01:31:09PM +1000, Damian Conway wrote:
> @refs = ^\ @list;
So does that mean that the Perl5 meaning of
@refs = \($a, $b, $c);
will go away? It seems like it should as it's a caretless hyper.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
Bryan asked:
> What about filetests that already return something meaningful? I'll
> assume that they still behave the same. (And thus, shouldn't be
> chained. Unless you're doing something weird.)
Yep.
> It's also mentioned that they don't short-circuit, so what do
> post-failu
> Imagine:
>
> @strings ^=~ s/pattern/replacement/;
>
> @refs = ^\ @list;
>
> @objects^.method();
>
> @values^++;
>
Both text-processing and number-crunching examples are here:
http://dev.perl.org/rfc/82.html#EXAMPLES
Adding the '^' before each operator is left as an exercise for the reade
** Discussion for RFC 320:
What about filetests that already return something meaningful? I'll assume
that they still behave the same. (And thus, shouldn't be chained. Unless
you're doing something weird.)
It's also mentioned that they don't short-circuit, so what do post-failure
tests te
> > And I didn't see anything about you being able to hyper =,
> > so ^= ought to be alright too.
>
> I would expect
>
>@a ^= 1; # sets default value for (all elems of) @a
>@a ^+= 1; # increments each element of @a
>
> etc.
Yep. AFAIK *every* operator (exce
> Set in stone, huh? Hmm. It may affect the parsing, but I'm not sure.
> Perhaps we can Arbitrarily Declare that an underscore isn't allowed as
> the last character of a symbol. That way, you can still do $foo_$bar
> without worrying about whitespace.
I doubt it. From E3:
> PS: I'm getting excited about the announcement of _sample_ code for a
> language _design_... That's kinda 'meta-vaporware' isn't it? Where did
> things go so wrong... ;-)
I've found it a real challenge to write that sort of code. It's an
constantly (and unsteadily) moving target, I
Brent Dax wrote:
> And I didn't see anything about you being able to hyper =,
> so ^= ought to be alright too.
I would expect
@a ^= 1; # sets default value for (all elems of) @a
@a ^+= 1; # increments each element of @a
etc.
Dave.
--
Dave Whipp, Senior Verification Engineer,
Damian Conway:
#> # solitary underscore for that. So, instead of:
#> # $a . $b . $c you'll say:
#> # $a _ $b _ $c The only downside to that is the
# space between a
#> # variable name and the
#> # operator is required. This is to be construed as a feature.
#>
#>
Damian Conway wrote:
>> But... earlier messages from
>> Larry suggested that the hyper-operator symbol would actually be an
adverb
>> (back then ':' was being proposed, IIRC), which sounded even more
>> exciting... Is this still the plan, with more to come in later
apocolypses
>
> # solitary underscore for that. So, instead of:
> # $a . $b . $c you'll say:
> # $a _ $b _ $c The only downside to that is the space between a
> # variable name and the
> # operator is required. This is to be construed as a feature.
>
> Ouch. Although I don't wish
> I haven't seen it mentioned here yet, so for those who haven't
> noticed A3 is now out:
> http://www.perl.com/pub/a/2001/10/02/apocalypse3.html
And Exegesis 3 will follow within 24 hours.
> But... earlier messages from
> Larry suggested that the hyper-operator symbol would actu
# Binary _
# Since . is taken for method calls, we need a new way to concatenate
strings. We'll use a
# solitary underscore for that. So, instead of:
#
# $a . $b . $c you'll say:
#
# $a _ $b _ $c The only downside to that is the space between a
variable name and the
# operator is required.
I haven't seen it mentioned here yet, so for those who haven't noticed A3 is
now out:
http://www.perl.com/pub/a/2001/10/02/apocalypse3.html
There's a lot to like here. I'll just cover 2 points for now though...
Larry's discussion of RFC 082, while not quite complete, does a great job of
learni
28 matches
Mail list logo
