hello,
sorry if this has been discussed before, I did a quick search in the
Archive and the summaries but can't find a similar topic.
I've just read A12, and while I really like the inherent orthogonality
of the whole object system as it is (will be) implemented, there is
something that puzzles m
On Fri, 2004-04-23 at 04:25, Aldo Calpini wrote:
> class MyClass {
> has LethalWeapon $.dispatcher;
> method meta { say "$_ is doing meta!" }
> }
>
> both of them would make my class pretty useless, I think, since it could
> not (correctly, at least) dispatch methods anymo
On Wed, 2004-04-21 at 12:44, Abhijit A. Mahabal wrote:
> On Wed, 21 Apr 2004, Brent 'Dax' Royal-Gordon wrote:
> > Which actually brings up an interesting question:
> >
> > class Silly {
> > has $.thing=1;
> > has @.thing=(2, 3);
> > has %.thing=(4 => 5, 6 => 7);
> >
On Wed, 2004-04-21 at 12:17, chromatic wrote:
> * Add a disambiguatey method to PoliceDog that dispatches
> appropriately. (Insert handwavey "well you *could* do it this way or
> you *might* do it that way.")
I agree, but given that the average user should probably not have to
interact with the
On Fri, Apr 23, 2004 at 10:37:00AM -0400, Aaron Sherman wrote:
: It's a fine point... in the past, P5 and P6 have up-cased such
: constructs in order to warn of their semi-keywordishness (e.g. DESTROY
: or BUILD). I'm wondering why Larry chose to leave dispatcher and meta
: lower in this case.
Hmm
At 8:24 AM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 10:37:00AM -0400, Aaron Sherman wrote:
: It's a fine point... in the past, P5 and P6 have up-cased such
: constructs in order to warn of their semi-keywordishness (e.g. DESTROY
: or BUILD). I'm wondering why Larry chose to leave di
(re-post. for some reason the alias didn't work.)
Larry Wall skribis 2004-04-23 8:24 (-0700):
> On the third hand, maybe we should go for $obj._meta_ or some such.
I don't like _foo_ names. Once you shart having things with underscores,
it's only a matter of time before someone decides that _foo
Aaron Sherman wrote:
seen the "does b". You could assert the other way around:
class c { does a for <>; does b for <>; }
which is kind of nifty looking, but some may blanch at the dual meaning
for "for"
Funny how similar that is to
class c { does a handles <>; does b handles <>; }
--
B
On Fri, 2004-04-23 at 11:44, Brent 'Dax' Royal-Gordon wrote:
> Aaron Sherman wrote:
> > class c { does a for <>; does b for <>; }
> Funny how similar that is to
>
> class c { does a handles <>; does b handles <>; }
In "Relationship to Roles" A12 makes the point that delegation and rol
Aaron Sherman wrote:
> However, in existing CPAN modules that I happen to have in my cache at
> the moment:
>
> [...]
>
> So it's not THAT bad.
hmmm... I think you should probably also grep for modules that do something
like:
my $self = {
meta => 'something',
dispatche
On Thu, Apr 22, 2004 at 04:46:39PM -0400, Aaron Sherman wrote:
: Prototyping in P6 would seem to me to be easy, but not quite the
: default. You'd want an intermediary that did the MetaClass negotiation
: as you "derived" from an existing object. Or will that be in the core?
: Can you say:
:
:
On Thu, Apr 22, 2004 at 02:21:17PM -0500, Abhijit A. Mahabal wrote:
: This is actually a couple of questions:
: 1: can you extend roles by saying: role Set is extended {}
Perhaps. Classes and objects that have already composed the role
would have to be notified that they need to recalculate colli
On Fri, Apr 23, 2004 at 09:42:51AM -0700, Larry Wall wrote:
: : return $self.keys.grep { exists $other{$^a} }
:
: grepping a hash?
Sorry--looked at that cross-eyed. Of course you can grep the keys...
Larry
On Fri, 2004-04-23 at 12:02, Aldo Calpini wrote:
> if Perl5 objects are to be implemented somewhat 'transparently' in Perl6,
> things like:
>
> $obj->{meta}
>
> will become:
>
> $obj.meta
>
> when used from Perl6. or not?
True enough, but this was just a quick exploration of the likel
At 2:21 PM -0500 4/22/04, Abhijit A. Mahabal wrote:
This is actually a couple of questions:
1: can you extend roles by saying: role Set is extended {}
Parrot will allow this, so if Larry says OK you're fine. It may be
rather significantly expensive, however. (Not nearly as bad as, say,
adding an
> -Original Message-
> From: Aaron Sherman [mailto:[EMAIL PROTECTED]
>
> On Fri, 2004-04-23 at 11:44, Brent 'Dax' Royal-Gordon wrote:
> > Aaron Sherman wrote:
>
> > > class c { does a for <>; does b for <>; }
>
> > Funny how similar that is to
> >
> > class c { does a handles <>; d
A12 sez:
If your delegation object happens to be an array:
has @:handlers handles 'foo';
then something cool happens. In this case
Perl 6 assumes that your array contains a list of potential
handlers, and you just want to call the first one that
succeeds.
This is not clear, and I
On Thu, Apr 22, 2004 at 10:34:25AM -0400, Aaron Sherman wrote:
: But, what happens if I:
:
: {
: use bytes;
: my string $line = $filehandlelikething.getline;
: }
That might depend on how $filehandlelikething was opened. A filehandle
is going to return a st
Austin Hastings writes:
> A12 sez:
>
> If your delegation object happens to be an array:
>
> has @:handlers handles 'foo';
>
> then something cool happens. In this case
> Perl 6 assumes that your array contains a list of potential
> handlers, and you just want to call the first one
On Fri, Apr 23, 2004 at 01:15:51PM -0400, Austin Hastings wrote:
: A12 sez:
:
: If your delegation object happens to be an array:
:
: has @:handlers handles 'foo';
:
: then something cool happens. In this case
: Perl 6 assumes that your array contains a list of potential
: handlers,
Mention is made of a typed undef in A12:
which doesn't quite work, because $spot is undefined. What probably happens
is that the my cheats and puts a version of undef in there that knows it
should dispatch to the Dog class if you call .self:new() on it. Anyway,
we'll make it work one way or anoth
Austin Hastings skribis 2004-04-23 13:33 (-0400):
> I should then be able to call class methods of Dog via $spot without further
> initialization:
> print defined($spot); # FALSE
> $rover = $spot.new;
> @breeds = $spot.list_breeds;
But shouldn't you then just use "my Class $spot = Dog" the
On Fri, Apr 23, 2004 at 11:28:02AM -0600, Luke Palmer wrote:
: Though the hash "handles" handler hardly seems useful to me. Perhaps
: someone can explain what that's intended to accomplish.
No idea. It just seemed like it ought to be made to mean something.
On the other hand, maybe making %:han
Juerd writes:
> Austin Hastings skribis 2004-04-23 13:33 (-0400):
> > I should then be able to call class methods of Dog via $spot without further
> > initialization:
> > print defined($spot); # FALSE
> > $rover = $spot.new;
> > @breeds = $spot.list_breeds;
>
> But shouldn't you then just
[EMAIL PROTECTED] (Austin Hastings) writes:
>
> which doesn't quite work, because $spot is undefined. What probably happens
> is that the my cheats and puts a version of undef in there that knows it
> should dispatch to the Dog class if you call .self:new() on it. Anyway,
> we'll make it work one
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
>
> On Fri, Apr 23, 2004 at 01:15:51PM -0400, Austin Hastings wrote:
> : A12 sez:
> :
> : If your delegation object happens to be an array:
> :
> : has @:handlers handles 'foo';
> :
> : then something cool happens. I
Interestingly, the opaque shortcut used to be
$class.bless(undef, *%_);
But I made it 0 instead merely because it's shorter. That does, however,
free up "undef" as a way of asking for an explicitly undefined but
blessed value.
: There are potentially two flavors of undef:
:
: undef
:
:
On Fri, Apr 23, 2004 at 10:39:33AM -0700, Larry Wall wrote:
: On the other hand, maybe making %:handlers special is wrong, and it
I meant @:handlers there, of course. We all seem to be having a
little trouble with syntax today, doesn't us?
Larry
> -Original Message-
> From: Juerd [mailto:[EMAIL PROTECTED]
>
> Austin Hastings skribis 2004-04-23 13:33 (-0400):
> > I should then be able to call class methods of Dog via $spot
> > without further initialization:
> > print defined($spot); # FALSE
> > $rover = $spot.new;
> > @br
On Fri, Apr 23, 2004 at 01:05:21PM -0400, Austin Hastings wrote:
: That seems like a good disambiguation marker, too:
:
: class Trog does Tree does Dog {...}
:
: # error: conflicting 'bark' methods
:
: class Trog
: is PersistentObject
: handles «meta dispatch SERIALIZE»
:
On Fri, 2004-04-23 at 14:17, Larry Wall wrote:
> : does Tree
> : handles «bark»
> : does Dog
> That works in the case of an explicitly named method, since that
> effectively makes .bark a method in the current class. It would not
> work for a wildcard delegation though, unles
On Fri, Apr 23, 2004 at 02:07:16PM -0400, Austin Hastings wrote:
: I guess I'm more strongly attached to the sigil than I realized. IMO, if you
: have
:
: $obj handles 'a';
:
: and put an arrayref in $obj, then you get what's coming: iteration. But if
: you have
:
: @obj handles 'a';
:
: th
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
>
> On Fri, Apr 23, 2004 at 01:05:21PM -0400, Austin Hastings wrote:
> : That seems like a good disambiguation marker, too:
> :
> : class Trog does Tree does Dog {...}
> :
> : # error: conflicting 'bark' methods
> :
> :
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
>
> Interestingly, the opaque shortcut used to be
>
> $class.bless(undef, *%_);
>
> But I made it 0 instead merely because it's shorter. That does, however,
> free up "undef" as a way of asking for an explicitly undefi
On Fri, 2004-04-23 at 14:28, Aaron Sherman wrote:
> I would expect wildcard delegation not to care about method conflicts at
> all, since what's being done is, by its nature, much more dynamic
> anyway.
I misunderstood roles when I said this... I now get why this is a
problem, sorry.
--
Aaron S
On Fri, Apr 23, 2004 at 02:50:42PM -0400, Austin Hastings wrote:
: Sure, but "You haven't provided a value yet." doesn't seem very ...
: exceptional.
The important thing will be "You didn't provide a value at line 42, though
you didn't actually try to use it till line 582."
: Sure -- the class of
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
>
> On Fri, Apr 23, 2004 at 02:07:16PM -0400, Austin Hastings wrote:
> : I guess I'm more strongly attached to the sigil than I
> realized. IMO, if you
> : have
> :
> : $obj handles 'a';
> :
> : and put an arrayref in $ob
On Tue, 2004-04-20 at 10:13, John Siracusa wrote:
> On 4/19/04 7:20 PM, Larry Wall wrote:
> > On Mon, Apr 19, 2004 at 06:53:29PM -0400, John Siracusa wrote:
> > : Yeah, that's exactly what I don't want to type over and over :)
> >
> > I really don't understand what you're getting at here. First y
> -Original Message-
> From: Larry Wall [mailto:[EMAIL PROTECTED]
>
> On Fri, Apr 23, 2004 at 02:50:42PM -0400, Austin Hastings wrote:
> : Sure, but "You haven't provided a value yet." doesn't seem very ...
> : exceptional.
>
> The important thing will be "You didn't provide a value at li
> -Original Message-
> From: Aaron Sherman [mailto:[EMAIL PROTECTED]
> Sent: Friday, 23 April, 2004 03:12 PM
> To: John Siracusa
> Cc: Perl 6 Language
> Subject: Re: A12: default accessors and encapsulation
>
>
> On Tue, 2004-04-20 at 10:13, John Siracusa wrote:
> > On 4/19/04 7:20 PM, La
On Fri, Apr 23, 2004 at 03:18:22PM -0400, Austin Hastings wrote:
: > -Original Message-
: > From: Larry Wall [mailto:[EMAIL PROTECTED]
: >
: > On Fri, Apr 23, 2004 at 02:50:42PM -0400, Austin Hastings wrote:
: > : Sure, but "You haven't provided a value yet." doesn't seem very ...
: > : exc
On Fri, Apr 23, 2004 at 03:13:09PM -0400, Austin Hastings wrote:
: Can I declare a const reference and have it optimized away?
:
: class Queue {
: has @:elements;
: has $:array_delegate
: handles
: = \@:elements
: is const;
: }
I suppose, depending on what you mean
"Larry Wall" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Fri, Apr 23, 2004 at 02:50:42PM -0400, Austin Hastings wrote:
> : Sure, but "You haven't provided a value yet." doesn't seem very ...
> : exceptional.
>
> The important thing will be "You didn't provide a value at line 4
On Fri, 2004-04-23 at 15:46, Dave Whipp wrote:
> Just wondering, are we going to have semantics similar to the old NaN Vs
> Signaling-Nan in IEEE floating point? An IEE NaN has an N-bit field where
> the source of the NaN can place a value representing the reason for the NaN.
> It can also set a f
On Fri, Apr 23, 2004 at 12:46:07PM -0700, Dave Whipp wrote:
: I'm not sure how much of this is relevant to C, but it might be nice
: to have the ability to have an undef that says "if used, then trap" (using
: the current "use fail" mode -- if that still exists)
I suppose one could give a typed un
On Fri, Apr 23, 2004 at 03:23:09PM -0400, Austin Hastings wrote:
: > And if you override the accessor, you can:
: >
: > multi method foo(Str $blah = undef) is rw($new) {
: > (my($old),$.foo)=($.foo,$blah//$new);
: > .update_the_world_in_some_cool_way();
: > r
"Then we simply claim that, under multiple dispatch, the "long name" of
any multi routine includes its signature, and that visibility is based on
the long name." (paragraph 3, "Multiple Dispatch")
Is a routine's "returns" trait also included in a multi routine's "long
name"? That is, if I define
Austin Hastings wrote:
> Jonathan Lang wrote:
> > role A {has Cat $.x;}
> > role B {has Dog $.x;}
> > class Foo {does Cat; does Dog;}
> > my Foo $bar;
> > $bar.x; # Is this a Cat or a Dog?
>
>
> If, however, two roles try to introduce a method of the same name (for
> some definition of name), t
On Fri, Apr 23, 2004 at 02:20:20PM -0700, Jonathan Lang wrote:
: "Then we simply claim that, under multiple dispatch, the "long name" of
: any multi routine includes its signature, and that visibility is based on
: the long name." (paragraph 3, "Multiple Dispatch")
:
: Is a routine's "returns" tra
At 2:37 PM -0700 4/23/04, Jonathan Lang wrote:
Austin Hastings wrote:
Jonathan Lang wrote:
> role A {has Cat $.x;}
> role B {has Dog $.x;}
> class Foo {does Cat; does Dog;}
> my Foo $bar;
> $bar.x; # Is this a Cat or a Dog?
If, however, two roles try to introduce a method of the same nam
On Fri, Apr 23, 2004 at 02:37:58PM -0700, Jonathan Lang wrote:
: Note that the problem extends past accessors: a role's methods can access
: its attributes directly. So:
:
: role A {has Cat $.x; method m1 {return $.x;};}
: role B {has Dog $.x; method m2 {return $.x;};}
: class Foo {does Cat
At the end of A12, "Exportation" covered the idea that you will now say:
sub foo() is export {...}
Rather than the P5:
@EXPORT=qw(foo);
sub foo;
Which is fine, except that in P5 we could say:
use Foo qw(foo);
@EXPORT=qw(foo);
Now, I know that the Apoc o
Can role definitions be nested? That is:
role A {
role subRole1 {...};
role subRole2 {...};
...
};
As I see it, this ought to be equivelent to
role A::subRole1 {...};
role A::subRole2 {...};
role A {
does A::subRole1; does A::subRole2;
...
};
The advantage of
How would I declare a subtype of a class which messes with the dispatching
mechanism to exclude certain methods and/or roles from it?
=
Jonathan "Dataweaver" Lang
__
Do you Yahoo!?
Yahoo! Photos: High-quality 4x6 digital prints for
Larry Wall wrote:
> On Fri, Apr 23, 2004 at 02:37:58PM -0700, Jonathan Lang wrote:
> : Note that the problem extends past accessors: a role's methods can
> : access its attributes directly. So:
> :
> : role A {has Cat $.x; method m1 {return $.x;};}
> : role B {has Dog $.x; method m2 {return $
Exporation?! And I sent one to p6i about "missint math ops" boy,
this is not my day :-(
But still, you get the idea, I hope ;-)
--
Aaron Sherman <[EMAIL PROTECTED]>
Senior Systems Engineer and Toolsmith
"It's the sound of a satellite saying, 'get me down!'" -Shriekback
Aaron Sherman wrote:
At the end of A12, "Exportation" covered the idea that you will now say:
sub foo() is export {...}
Rather than the P5:
@EXPORT=qw(foo);
sub foo;
Which is fine, except that in P5 we could say:
use Foo qw(foo);
@EXPORT=qw(foo);
Now, I know th
On Sat, Apr 24, 2004 at 09:52:12AM +1000, Damian Conway wrote:
: My proposal for that issue is just:
:
: module Bar;
:
: use Foo «foo»;
:
: sub foo is export {...}
That's on the right track, but has some difficulties, insofar as it's
not clear that the intent is to redefine "f
On Fri, Apr 23, 2004 at 03:34:32PM -0700, Jonathan Lang wrote:
: Larry Wall wrote:
: > On Fri, Apr 23, 2004 at 02:37:58PM -0700, Jonathan Lang wrote:
: > : Note that the problem extends past accessors: a role's methods can
: > : access its attributes directly. So:
: > :
: > : role A {has Cat $.
On Fri, Apr 23, 2004 at 03:00:57PM -0700, Jonathan Lang wrote:
: Can role definitions be nested? That is:
:
: role A {
: role subRole1 {...};
: role subRole2 {...};
: ...
: };
:
: As I see it, this ought to be equivelent to
:
: role A::subRole1 {...};
: role A::subRole2 {.
On Fri, Apr 23, 2004 at 03:07:23PM -0700, Jonathan Lang wrote:
: How would I declare a subtype of a class which messes with the dispatching
: mechanism to exclude certain methods and/or roles from it?
Er, uh...tell you what. Why don't you provide some sample code to
go with your question, and
Larry wrote:
On Sat, Apr 24, 2004 at 09:52:12AM +1000, Damian Conway wrote:
: My proposal for that issue is just:
:
: module Bar;
:
: use Foo «foo»;
:
: sub foo is export {...}
That's on the right track, but has some difficulties, insofar as it's
not clear that the intent is to redefine "fo
One of the beauties of the original Traits paper was that its roles had
ways of specifying assertions of what criteria must be met by whatever
classes they were to be composed into. Meanwhile, it's been mentioned
that roles and classes in P6 might look declarative in nature, but they
are in fact p
At 6:12 PM -0700 4/23/04, Larry Wall wrote:
On Fri, Apr 23, 2004 at 03:07:23PM -0700, Jonathan Lang wrote:
: How would I declare a subtype of a class which messes with the dispatching
: mechanism to exclude certain methods and/or roles from it?
Er, uh...tell you what. Why don't you provide some
On Fri, Apr 23, 2004 at 06:56:35PM -0700, Jonathan Lang wrote:
: $::_ can x; # asserts that the class must provide a method called x
Fine idea, but that looks like run-time code that runs at the wrong time.
It needs something out front to make it a declaration. Perhaps it's just:
POST {
Uri Guttman asked:
how would you handle %EXPORT_TAGS and @EXPORT_OK?
Export-only-by-request (i.e. @EXPORT_OK) becomes the default.
The tag names become arguments to C:
sub foo is export(:BAR, :FOOLISH) {...} # Now in two named tagsets
Every exportable is automatically also in the :ALL tagset
Larry Wall wrote:
> Jonathan Lang wrote:
> : How would I declare a subtype of a class which messes with the
> : dispatching mechanism to exclude certain methods and/or roles from
> : it?
>
> Er, uh...tell you what. Why don't you provide some sample code to
> go with your question, and we'll j
(Note: throughout this message, "method" refers to "sub"s and
"submethods" as well.)
I'm having trouble coming up with a solid argument for why Single Method
Dispatch (SMD) is our default, when we have MMD.
At this point, I'm tempted to slap a C in front of all my
methods, for the sake of futur
68 matches
Mail list logo
