Author: wayland
Date: 2009-03-16 09:23:53 +0100 (Mon, 16 Mar 2009)
New Revision: 25853
Modified:
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
Fix typo for TimToady++ (I like the new changes :) )
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
Author: wayland
Date: 2009-03-16 09:35:04 +0100 (Mon, 16 Mar 2009)
New Revision: 25854
Modified:
docs/Perl6/Spec/S32-setting-library/IO.pod
Log:
Removed IO::File::Windows, as it's no longer necessary, AFAIK.
Modified: docs/Perl6/Spec/S32-setting-library/IO.pod
On Mar 15, 12:57 pm, datawea...@gmail.com (Jon Lang) wrote:
The problem that Richard just identified is that Junctions don't fully
manage to hide themselves when it comes to their method calls.
[...]
I'm thinking that maybe Junction shouldn't be a type. Instead, it
should be a meta-type, in
Sigh. The current design of Junctions is quite extensible *because*
it is based on a real type. You can easily write operators that
work only on Junctions, just as you can easily write operators that
are transparent to Junctions or autothread on Junctions by declaring
their arguments to take
Having a problem with the following role in Perl 5:
package PIPs::ResultSource::Role::HasTags;
use Moose::Role;
requires 'do_setup';
after 'do_setup' = sub { ... };
So far this has worked really well, aside from that one class which didn't call
'do_setup'. Oops.
Requiring methods and
Larry Wall wrote:
Sigh. The current design of Junctions is quite extensible *because*
it is based on a real type. You can easily write operators that
work only on Junctions, just as you can easily write operators that
are transparent to Junctions or autothread on Junctions by declaring
Ovid wrote:
Requiring methods and requiring methods to be called are different things.
It might be a nice feature to have roles which tie into events. If a
particular condition doesn't hold true by, say, INIT time, the role fails.
How would I implement something like that in Perl 6? Or
Ovid wrote:
Having a problem with the following role in Perl 5:
package PIPs::ResultSource::Role::HasTags;
use Moose::Role;
requires 'do_setup';
after 'do_setup' = sub { ... };
So far this has worked really well, aside from that one class which didn't call
'do_setup'. Oops.
OK: as I see it, this is how signatures work:
There are three broad use-cases for signatures: function parameters
(S06), role parameters (S14), and variable declarators (S03).
Question: Do binding operators (S03) count as a fourth use?
There are two broad styles of signatures: those that want an
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
they're probably
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum mechanics in Perl 6,
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be programming quantum
Darren Duncan wrote:
Jon Lang wrote:
Larry Wall wrote:
This is basically a non-problem. Junctions have one public method,
.eigenstates, which is vanishingly unlikely to be used by accident by
any mere mortal any time in the next 100 years, give or take a year.
If someone does happen to be
On Mon, Mar 16, 2009 at 09:24:58PM -0700, Jon Lang wrote:
: Darren Duncan wrote:
: Jon Lang wrote:
: Larry Wall wrote:
: This is basically a non-problem. Junctions have one public method,
: .eigenstates, which is vanishingly unlikely to be used by accident by
: any mere mortal any time in
14 matches
Mail list logo
