Beefy Boxes and Bandwidth Generously Provided by pair Networks
Just another Perl shrine
 
PerlMonks  

Re: Re: Thoughts on some new operators for perl (6 or 7)

by hardburn (Abbot)
on Mar 10, 2004 at 14:17 UTC ( #335451=note: print w/replies, xml ) Need Help??


in reply to Re: Thoughts on some new operators for perl (6 or 7)
in thread Thoughts on some new operators for perl (6 or 7)

.= is already in Perl5. But the period is a completely different operator in Perl6, and .= doesn't make sense for its new purpose (it's for obj.method calls, just like many other OO langs).

----
: () { :|:& };:

Note: All code is untested, unless otherwise stated

Replies are listed 'Best First'.
Re: Re: Re: Thoughts on some new operators for perl (6 or 7)
by Juerd (Abbot) on Mar 10, 2004 at 14:26 UTC

    .= doesn't make sense for its new purpose

    If you can't imagine a function for it, it automatically does not make sense?

    It could very well become a mutator for objects. As $foo += 5 equals $foo = $foo + 5, $foo .= lc could equal $foo = $foo.lc. Especially for @foo.sort and @foo.=sort, this would be great to have.

    I've been wanting mutating and non-mutating versions of builtins for a while now, and this seems to me a good way to do it.

    See also Re: Re: What should be returned in scalar context?.

    Does it make sense now?

    Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

      Sense, yes. But pulling the method and object apart like that is uglier than its worth, IMHO. If you want mutating on an object, than you should define method to work that way already.

      ----
      : () { :|:& };:

      Note: All code is untested, unless otherwise stated

        If you want mutating on an object, than you should define method to work that way already.

        No, that is exactly the opposite of what I want. That way you get again the mess that Perl 5 also has: some are mutating, some are not. I want everything to be non-mutating by default with some kind of modifier to make it mutating. This thread made me think of .= and I think it is a very good candidate, because it works much like the other op= operators: foo op= bar does the same as foo = foo op bar, but with possible optimizations.

        Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://335451]
help
Chatterbox?
[ambrus]: Corion: push_write is in the higher level abstraction of AnyEvent::Handle, not in the watcher
[Corion]: ambrus: Hmm - rereading Prima::File, that merrily coincides with what Prima does - it tells you "you can read", and you're supposed to read from the fh yourself. I thought it called you with the data already read, which would've been harder to integrate
[ambrus]: you just need an io watcher, created by &AnyEvent::Impl:: Whatever::io(...)
[Corion]: So after talking it through with you even while I'm still not entirely clear on where AE ends and my implementation begins, I think I understand that I only need to implement some smaller parts for each functionality I want to support.
[Corion]: Yeah... and you might even be able to mix and match additional functionality if you have additional async suppliers, like from a separate thread
[ambrus]: You hvae to be careful with the timer, because apparently Prima::Timer insists on being periodic, wheras AnyEvent::Impl:: Whatever::timer should give a one-shot timer watcher
[ambrus]: I think the minimal implementation here is just a timer and io function, plus pushing to the @REGISTRY.

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (6)
As of 2016-12-08 12:23 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    On a regular basis, I'm most likely to spy upon:













    Results (141 votes). Check out past polls.