Damian Conway wrote:
Let's assume that op is overloaded for two completely unrelated types
A and B, which are both defining their respective identity elements
but !(A.identval =:= B.identval). How should the op multi method object
pick the correct one *without* looking at $value's type?
Your
Damian Conway wrote:
No. That needs to be:
method greet(FooClass ::class:) { say Hello!; }
(as implied by takes a class as its invocant in S12).
^
Ohh, does that mean that ::class can be used as a type
inside the body? E.g.
method template ( FooClass ::foo
On Fri, Jun 17, 2005 at 08:13:55AM +1000, Damian Conway wrote:
Patrick wrote:
method greet(FooClass $class:) { say Hello!; }
No. That needs to be:
method greet(FooClass ::class:) { say Hello!; }
(as implied by takes a class as its invocant in S12).
Okay, I'm a bit confused.
On Fri, Jun 17, 2005 at 09:19:17AM +0200, TSa (Thomas Sandla) wrote:
: Ohh, does that mean that ::class can be used as a type
: inside the body? E.g.
:
: method template ( FooClass ::foo :)
: {
:my foo $f;
:
:... # use $f
: }
Certainly. It's exactly the same situation as a func formal
On Thu, Jun 16, 2005 at 10:28:26PM +, Luke Palmer wrote:
: You know, before I read this part of the message, I was thinking
: precisely that. Nullary splat should do it, so that @foo[*] will
: work. Unary splat would of course get our favor if it can be
: interpreted that way, but in cases
On Fri, Jun 17, 2005 at 04:41:53AM +0100, Piers Cawley wrote:
: Suppose I have a simple, single argument recursive function:
:
: sub factorial (Int $n) {
: return 1 if $n == 0;
: return $n * factorial $n;
: }
:
: Can I write that as:
:
: sub factorial (Int $n:) {
: return 1
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?
Yes.
: rule variable { sigil name [ \( siglet \) ]? }
: rule sigil { [EMAIL PROTECTED]] [*.:?^=]? }
rule sigil { [ [EMAIL PROTECTED]] | '::' ] [*.:?^=]? }
which
On Fri, Jun 17, 2005 at 11:56:11AM -0700, Larry Wall wrote:
On Fri, Jun 17, 2005 at 09:03:57AM -0500, Patrick R. Michaud wrote:
: Is '::' acting as a sigil here?
Yes.
: rule variable { sigil name [ \( siglet \) ]? }
: rule sigil { [EMAIL PROTECTED]] [*.:?^=]? }
Larry Wall wrote:
Can anyone think of a good reason not to topicalize the first arg
of ordinary subs these days? Other than subtle encouragement toward
use of multis? I suppose it also makes refactoring between subs and
methods more difficult in the case where you're adding an invocant,
On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
: Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
: want to lose the abilities described above. How would those examples look
: in native Perl 6 code? (i.e., Without forcing all methods to have a
: single
On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
:
: my $x = 3;
: my $y = \$x;
: say $y + 10;
: $y++;
: say $y;
: say $x;
:
: Currently in Pugs they print:
:
: 13
: 4
: 3
:
: Is this sane? What is the scalar reference's semantics in face of a
Larry Wall wrote:
On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
:
: my $x = 3;
: my $y = \$x;
: say $y + 10;
: $y++;
: say $y;
: say $x;
:
: Currently in Pugs they print:
:
: 13
: 4
: 3
:
: Is this sane? What is the scalar reference's
On 6/17/05, Larry Wall [EMAIL PROTECTED] wrote:
On Fri, Jun 17, 2005 at 03:56:50AM +0800, Autrijus Tang wrote:
:
: my $x = 3;
: my $y = \$x;
: say $y + 10;
: $y++;
: say $y;
: say $x;
:
I suspect people will find that counterintuitive. A more consistent
On 6/17/05, Larry Wall [EMAIL PROTECTED] wrote:
On Thu, Jun 16, 2005 at 05:18:51PM -0400, John Siracusa wrote:
: Now in Perl 6 I'll want to use fancy named parameters and so on, but I don't
: want to lose the abilities described above. How would those examples look
: in native Perl 6 code?
On Fri, Jun 17, 2005 at 02:29:08PM -0500, Rod Adams wrote:
: Don't you mean:
:
:13
:4
:4
:
: ?
Er, yes. Sorry I've been spouting vaguely incoherent spoutings this
week, but I've been up several times every night trying to deal with a
masked bandit that likes to sneak in the cat
Larry wrote:
: Can I write that as:
:
: sub factorial (Int $n:) {
: return 1 when 0;
: return $n * factorial $n;
: }
As it stands right now, no. Ordinary subs do not allow invocants.
Arguably, it'd be more consistent if ordinary subs always topicalized
their first argument.
John Siracusa wrote:
(BTW, I'm not sure where those ./ thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be .)
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the current topic.
Unary ./ calls a specified
On Sat, Jun 18, 2005 at 08:18:17AM +1000, Damian Conway wrote:
The point being that methods no longer topicalize their invocant.
To update the design docs, A06 currently says:
Methods, submethods, macros, rules, and pointy subs all
bind their first argument to C$_; ordinary subs
On Sat, 18 Jun 2005, Damian Conway wrote:
John Siracusa wrote:
(BTW, I'm not sure where those ./ thingies came from, but it's what
GMail
showed in your message. I'm assuming it should just be .)
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the
On 6/17/05 6:18 PM, Damian Conway wrote:
John Siracusa wrote:
(BTW, I'm not sure where those ./ thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be .)
No. There's now also a unary ./ operator in Perl 6.
Unary . calls a specified method on the
Abhijit Mahabal asked:
Er, is it true that methods don't topicalize the invocant nowadays?
If it's not true, it darn well ought to be!
I had thought that they do and one needs the ./ to still talk about the
invocant if some inner loop stole the $_, and until such stealing occurs
.foo()
John Siracusa wrote:
Wow, that..er...how did I miss that? It looks a lot like running an
executable in the current dir instead of letting the shell search its path.
That's the mnemonic, yes. Call this functionality relative to the current
location (i.e. invocant).
Was this syntax
(Yes, the subject line is a ps joke...it's late...well, late for a new
parent, anyway.)
On 6/17/05 6:18 PM, Damian Conway wrote:
John Siracusa wrote:
(BTW, I'm not sure where those ./ thingies came from, but it's what GMail
showed in your message. I'm assuming it should just be .)
No.
Oops, part of Diamian's quoted text got trimmed accidentally in my last
post. It should have looked like this:
On 6/17/05 10:42 PM, John Siracusa wrote:
[...] I'm not, however, buying Damian's argument here:
On 2005-05-15 20:33:19, [EMAIL PROTECTED] (Damian Conway) said:
This missing
On Jun 17, 2005, at 10:42 PM, John Siracusa wrote:
But the truth is that /
really does look file-path-y to me, and just plain old ugly. I
think at
least two other people had similar reactions (Martin Kuehl and Carl
Franks).
David Storrs, reporting to show solidarity, sir(acusa)!
Maybe
On 6/17/05 10:56 PM, David Storrs wrote:
I'm not fond of .:: because I don't think it's sufficiently visually
distinct from .:.
Hm, let's look at it:
method total(...)
{
.::sanity_check();
return .:value_one() + .:value_two();
}
Maybe lined up?
26 matches
Mail list logo
