By the way: if you override an operator, you can still access the original one
using CORE::
sub infix:<+>($,$) { 42 }
say 200 + 300; # 42
say infix:<+>(200,300); # 42
say &CORE::infix:<+>(200,300); # 500
> On 26 Nov 2021, at 20:30, rir wrote:
>
> Wow,
You mean like:
say &infix:<+>(has 42,137); # 179
?? If so, by referring to its full name :-)
> On 26 Nov 2021, at 15:07, rir wrote:
>
> Is it possible to to delegate plain or overridden operators? If so,
> what does the syntax look like?
>
> Rob
Is it possible to to delegate plain or overridden operators? If so,
what does the syntax look like?
Rob
Still reproducible (2017.11,HEAD(e5b660e))
On 2015-03-06 14:35:06, rayd...@cyberuniverses.com wrote:
> As seen at http://irclog.perlgeek.de/perl6/2015-03-06#i_10237611 :
>
> r: role R { method foo () handles { } }
> rakudo-moar 1b74e4: OUTPUT«===SORRY!=== Error while compiling
> /tmp/tmpfileMeth
Hi,
According to synopsis 12 I could defer methods to methods in another object.
The case in which one can map some name into another didn't work out.
*
**
**class A {**
** method say-i (Int $i ) { say "I: $i"; }**
**}**
**
**class B {**
** has A $.n handles { :x };**
**
** submethod BUILD { $
# New Ticket Created by
# Please include the string: [perl #124007]
# in the subject line of all future correspondence about this issue.
# https://rt.perl.org/Ticket/Display.html?id=124007 >
As seen at http://irclog.perlgeek.de/perl6/2015-03-06#i_10237611 :
r: role R { method foo () handles
test added by peschwa++, closing ticket.
--
Will "Coke" Coleda
($x) { say "OH HAI" }; method foo
> {
> > self.bar(42) } }; R.new.foo
> > rakudo 922500: OUTPUT«OH HAI»
> > and it seems that, somehow, the role method delegation is
> > necessary to trigger it.
>
> The second variant no longer errors. If you
ram body at line
> 22:/tmp/N060_2D3In»
> * masak submits rakudobug
> only the order of the method declarations in the role differs.
> rakudo: role R { method bar($x) { say "OH HAI" }; method foo {
> self.bar(42) } }; R.new.foo
> rakudo 922500: OUTPUT«OH HAI»
> and it s
On Wed Jul 08 03:59:21 2009, masak wrote:
> rakudo: class A { method foo {"A.foo"} }; class C { has A $.a
> handles *; }; my C $c .= new; say C.foo
> rakudo 70bfd5: OUTPUT«Method 'foo' not found for invocant of
> class ''»
> NYI?
> I'm sure we had tests for handles *
> oh
> rakudo: class A {
{ say "OH HAI" }; method foo {
self.bar(42) } }; R.new.foo
rakudo 922500: OUTPUT«OH HAI»
and it seems that, somehow, the role method delegation is
necessary to trigger it.
Message:
---
Defer wildcard delegation to dispatch failover
Wildcard delegation should not be used for methods that are in
the object's own ancestry (especially .new). Use explicit delegation
or mixins to acquire such methods.
Commit: af947e981ca92e316a4841a022b52f23230e464f
rakudo: class A { method foo(|$c) { say $c.perl } }; A.foo
rakudo ad2afb: OUTPUT«\()»
rakudo: class A { method foo(|$c) { say $c.perl } }; A.foo(1)
rakudo ad2afb: OUTPUT«Too many positional parameters passed; got 2 but
expected
2 in 'A::foo' at line 11:/tmp/TE5FBvA4r9 [...]
Golfed.
* masa
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #75966]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=75966 >
rakudo: class A { method foo($x) { say "OH $x" } }; class B
{ has $.a handles }; B.new
# New Ticket Created by "Carl Mäsak"
# Please include the string: [perl #67324]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=67324 >
rakudo: class A { method foo {"A.foo"} }; class C { has A $.a
handles *; }; my C $c .=
ot a perl 6.0.0 feature, but
something that it shouldn't be too difficult to add later) would be a
way to tell the delegation to pass "self" as an extra arg to the
delegate method.
The |$args does include the $self as the first argument. The syntax
tail.wag(|$args) will star
I noted Jonathan Worthington's work implementing the "handles" trait for
delegation through attributes, and was a bit surprised to see that it is
defined (S12/delegation) to use strings instead of method signatures --
I had thought that perl6 was attempting to be symbolic in plac
Felix Gallo (via RT) wrote:
Synopsis: in CVS as of Tue Aug 10 17:30:52 EDT 2004, the
examples/japh/japh[4,5,6,9].pasm examples all crash with
segmentation fault on my highly hacked up linux box.
Ah, yep thanks.
They arguably should be working fine.
IO changes WRT output line-buffering made thread-
# New Ticket Created by Felix Gallo
# Please include the string: [perl #31050]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31050 >
Synopsis: in CVS as of Tue Aug 10 17:30:52 EDT 2004, the
examples/japh/japh[4,5,6,9].p
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
d it shouldn't have to
> go poking down through a reference to get at that list. It has a valid
> use for the @ sigil.
Aha! A light comes on:
Delegation is not the same as subordination.
The C delegation syntax declares "formal"
delegation, meaning that the handler
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
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: 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';
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
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
:
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, an
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
> [proposal for delegation syntax, drawing from Class::Delegation]
>
> If something is part of the method interface, it ought to be declared
> as a method.
>
> method steer is really(Wheel) is also(???) { .profit!!! }
That's tidy, and is sorta on the lines of my own
: Problem:
:
: You want to use delegation rather than inheritance to
: add some capabilities of one class or object to
: another class or object.
:
: Solution:
:
: Use a PROXY block:
:
: class MyClass {
:
: PROXY {
: attr $left_front_wheel is Wheel;
: attr
Problem:
You want to use delegation rather than inheritance to
add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel
Problem:
You want to use delegation (rather than inheritance)
to add some capabilities of one class or object to
another class or object.
Solution:
Use a PROXY block:
class MyClass {
PROXY {
attr $left_front_wheel is Wheel;
attr $right_front_wheel is Wheel
John Williams:
> Reaction #2: Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve
> the problem?
What about when you want to be able to dynamically swap the objects to which
you're delegating?
--
Garrett Goebel
IS Development Special
At 12:37 AM -0400 10/4/02, Michael G Schwern wrote:
>Delegation is a basic OO technique. We definately should have fast,
>well-designed core support for it.
I'm pretty sure we will. I certainly need it internally...
--
ct inherits all the methods that
you don't explicity re-define.
With interfaces, you are stating that your object will implement
all the methods, either directly or by inheriting from, or delegating
to other classes.
Thus, inheritance, delegation and interfaces are separate, orthogon
On Fri, Oct 04, 2002 at 12:28:29AM -0400, Trey Harris wrote:
> I think my point here is that there are clearly places where we need
> stronger built-in support in Perl of some OO concepts. Delegation may not
> be one of them--it's easy enough to graft on, and TMTOWTDI may
On Thu, Oct 03, 2002 at 07:59:33PM -0600, John Williams wrote:
> Reaction #2: Inheritance would automatically delegate all those
> methods, so again, in what way does inheritance _not_ solve the problem?
I don't think p6l is the right place to discuss the merits of delegation,
let
In a message dated Thu, 3 Oct 2002, Michael Lazzaro writes:
> On Thursday, October 3, 2002, at 04:25 PM, Michael G Schwern wrote:
> > Class::Delegation?
>
> Yeah, it's one of the best I've seen: it makes sense, does everything I
> want, and is easy to explain even
On Thu, 3 Oct 2002, Michael Lazzaro wrote:
>
> 1) Delegation through inheritance:
> (a.k.a. "mixin" classes, "hard delegation", "concrete interfaces",
> etc., etc.)
>
> Example: I want to say that a class DataManager has the capabil
lly ever liked.
>
> Class::Delegation?
Yeah, it's one of the best I've seen: it makes sense, does everything I
want, and is easy to explain even to newbies. The perl5 hash-based
syntax is still pretty scary, tho.
Dunno, I keep wishing for something that's a one-li
On Thu, Oct 03, 2002 at 03:54:09PM -0700, Michael Lazzaro wrote:
> I have no *good* syntax proposals for this, I don't think I've ever
> seen the problem solved with syntax that I really ever liked.
Class::Delegation?
--
Michael G. Schwern <[EMAIL
n D&E.
Oh, thank God. I was hoping people would say that.
OK, for an entirely different thread...
Is there an accepted preliminary syntax for OO delegation? (I've
looked and can't find anything definitive.) By "delegation", I mean
two different things (you can tell OO p
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Core support for method delegation
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 Sep 2000
Last Modified: 25 Sep 2000
Mailing List: [EMAIL PROTECTED]
Numbe
> > When you want to turn off an inherited delegation in an ISA situation?
>
> Um, I don't think I understand the question.
I'm confused by the question, too.
> Delegation is not inherited. Any module you inherit from you won't
> use f
"David L. Nicol" wrote:
>
> When you want to turn off an inherited delegation in an ISA situation?
Um, I don't think I understand the question. Delegation is not
inherited. Any module you inherit from you won't use for delegation,
AFAIK. They're two different be
When you want to turn off an inherited delegation in an ISA situation?
"David E. Wheeler" wrote:
>
> Damian Conway wrote:
>
> > Err, that *is* the default behaviour. Delegation doesn't occur unless
> > you specify it. Or am I missing your meaning h
> use delegation
> attr1 => [qw( method1 method2 method3 )],
> attr2 => [qw( method4 method5 )],
> attr3 => __ALL__, # Use all of them.
> attr4 => []; # Use none of them.
>
> Yes, I realize that not putting attr4 in there
Damian Conway wrote:
> Err, that *is* the default behaviour. Delegation doesn't occur unless
> you specify it. Or am I missing your meaning here?
use delegation
attr1 => [qw( method1 method2 method3 )],
attr2 => [qw( method4 method5 )],
attr3 => __ALL_
>
> Unless you change the default behavio[u]r to "don't delegate any method
> calls to this object!".
Err, that *is* the default behaviour. Delegation doesn't occur unless
you specify it. Or am I missing your meaning here?
Damian
Damian Conway wrote:
>
> Stupid, stupid, stupid! Of course, that should be:
>
> attr3 => __ALL__
>
> and then delegated methods can be named any(crazy)thing.
Damn, Damian, don't be so hard on yourself! You're right about __ALL__,
of course, but I suspect that most of us would have a pr
Damian Conway wrote:
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
>
> so that classes can still have an C method delegated.
> (Yes, now they can't have an C<__ALL__> method,
> but maybe that's a Good Thing ;-)
Agreed. Yes, that's very goo
Damian Conway wrote:
>
>> attr3 => [ALL]
>
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
Any consideration given to the :all export-like tag?
attr3 => [:all]# could be uppercase too
-Nate
Too early in the morning, I wrote:
>> I might like to see something like URI suggested:
>>
>> attr3 => [ALL]
>
> It was (and is) a good suggestion. I suspect however that it should be
>
> attr3 => [__ALL__]
>
> so that classes can still have an C
> When I see those empty arrayrefs, I think "delegate to *no* methods in
> those classes stored in attr3 and att4," rather than "delegate all
> method calls to those attributes." Just in the name of greater clarity,
> I might like to see something like URI suggested:
>
> attr3
> Is this not just a module which creates the necessary subs in the calling
> package ? The catchall can be done with an AUTOLOAD sub.
That's certainly how Class::Delegation is implemented.
It isn't quite adequate however, because if you trigger the AUTOLOAD and
it *fa
Perl6 RFC Librarian wrote:
>
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Core support for method delegation
This idea rocks, Damian! I want it now! Just one suggestion, however...
> The proposed delegat
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> The proposed delegation mechanism would work via a pragma:
>
> use delegation
> attr1 => [qw( method1 method2 method3 )],
> attr2 => [qw( method4 method5 )],
Michael G Schwern <[EMAIL PROTECTED]> writes:
> On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> > Objects : Core support for method delegation
>
> I like it! One gripe (of course)...
>
>
> > The proposed delegation mechanism would wo
Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
> This and other RFCs are available on the web at
> http://dev.perl.org/rfc/
>
> =head1 TITLE
>
> Objects : Core support for method delegation
I *want* this. Delegation is cool. Delegation that gets set up at
compile ti
>>>>> "DC" == Damian Conway <[EMAIL PROTECTED]> writes:
PRL> use Class::Delegation
>>
>> shouldn't that be use delegation? i think you have a cut and paste
>> error.
DC> You're correct. Many thanks.
DC> (That
On Mon, Sep 04, 2000 at 09:53:39PM -, Perl6 RFC Librarian wrote:
> Objects : Core support for method delegation
I like it! One gripe (of course)...
> The proposed delegation mechanism would work via a pragma:
>
> use delegation
> attr1 => [qw( metho
> PRL> One powerful application of delegation is as a replacement for
> PRL> inheritance where the internals of a prospective base class are
> PRL> inaccessible or inconvenient, or the base class was not designed
> PRL> to be inherited and yet it must b
>>>>> "PRL" == Perl6 RFC Librarian <[EMAIL PROTECTED]> writes:
PRL> One powerful application of delegation is as a replacement for
PRL> inheritance where the internals of a prospective base class are
PRL> inaccessible or inconvenient, or the
This and other RFCs are available on the web at
http://dev.perl.org/rfc/
=head1 TITLE
Objects : Core support for method delegation
=head1 VERSION
Maintainer: Damian Conway <[EMAIL PROTECTED]>
Date: 4 September 2000
Mailing List: [EMAIL PROTECTED]
Version: 1
Number: 193
64 matches
Mail list logo
