At 5:45 PM -0400 10/4/06, Aaron Sherman wrote:
I'm noodling around with the idea of creating an archive and index
of all of the messages to the mailing list over the years for
purposes of quickly finding all of the messages that have definitive
information on a given topic. Simply searching on
Author: larry
Date: Wed Oct 4 21:55:49 2006
New Revision: 12681
Modified:
doc/trunk/design/syn/S12.pod
Log:
forgot date change.
Modified: doc/trunk/design/syn/S12.pod
==
--- doc/trunk/design/syn/S12.pod(orig
Author: larry
Date: Wed Oct 4 21:23:57 2006
New Revision: 12678
Modified:
doc/trunk/design/syn/S05.pod
Log:
y/// is dead.
Modified: doc/trunk/design/syn/S05.pod
==
--- doc/trunk/design/syn/S05.pod(original)
Author: audreyt
Date: Wed Oct 4 21:16:26 2006
New Revision: 12675
Modified:
doc/trunk/design/syn/S12.pod
Log:
* S12: Remove the troublesome single-arg-function-become-method rule:
sub foo (*$x) { $x }
foo(want); # Always in list context, never evaluated as "want.foo"
As an altern
Trey Harris wrote:
I read it as "yes, you *can* put strictures on the using code into a
library, though I wouldn't do it and would say that any module that does
so shouldn't be released on CPAN for general use. ..."
Hey, I have an idea. Let's write a module that enforces that!
Seriously, I t
I'm noodling around with the idea of creating an archive and index of
all of the messages to the mailing list over the years for purposes of
quickly finding all of the messages that have definitive information on
a given topic. Simply searching on Google or through my mail spool just
doesn't cu
In a message dated Wed, 4 Oct 2006, Jonathan Lang writes:
In Perl 6, the abstract SystemMonitor could be a role, and a concrete
ScriptedMonitor could be a class that does SystemMonitor, but it's not at
all clear to me what HardwareMonitor would be, since classes can't be
abstract and roles can't
On Wednesday 04 October 2006 13:25, Trey Harris wrote:
> I read it as "yes, you *can* put strictures on the using code into a
> library, though I wouldn't do it and would say that any module that does
> so shouldn't be released on CPAN for general use. But even if you can do
> that, you *must* al
In a message dated Wed, 4 Oct 2006, jesse writes:
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote:
The point is that the person writing the program decides which handcuffs or
costumes all of the code has to wear, not the person writing the libraries.
If you want to set a policy for you
On Wed, Oct 04, 2006 at 12:01:22PM -0700, chromatic wrote:
> On Wednesday 04 October 2006 01:05, jesse wrote:
>
> > One of the things that many shops have defected from Perl to Java for
> > is the additional handcuffs that Java provides for less-than-experienced
> > developers. Giving me the p
On Wednesday 04 October 2006 12:48, jesse wrote:
> Ok. So, I think what you're saying is that it's not a matter of "don't let
> people write libraries that add strictures to code that uses those modules"
> but a matter of "perl should always give you enough rope to turn off any
> stricture imposed
On Wednesday 04 October 2006 12:09, jesse wrote:
> Perhaps I'm misunderstanding what you mean by "person writing the
> program" and "person writing the libraries." In fact, I've _gotta_
> be. I'd like to be able to put my strictures in a library rather than
> forcing them into the main body of a
On Wednesday 04 October 2006 01:05, jesse wrote:
> One of the things that many shops have defected from Perl to Java for
> is the additional handcuffs that Java provides for less-than-experienced
> developers. Giving me the power to control what my team, or folks using
> my language variant, do c
On Wed, Oct 04, 2006 at 10:35:05AM -0400, Aaron Sherman wrote:
: Damian Conway wrote:
:
: > @bar».foo if $baz;
:
: That brought to mind the question that I've had for some time: how are
: exceptions going to work on hyper-operators?
:
: Will they kill the hyperoperation in-progress? e.g. what
Trey Harris wrote:
It sounds like the assumption thus far has been that the existance of
roles imply that abstract classes are disallowed, so you'd write:
role Dog { method bark { ... } #[ ... ] }
class Pug does Dog { method bark { .vocalize($.barkNoise) } }
S12 says: "Classes are primari
Aaron Sherman wrote:
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
Corrected example follows (there were s
Damian Conway wrote:
@bar».foo if $baz;
That brought to mind the question that I've had for some time: how are
exceptions going to work on hyper-operators?
Will they kill the hyperoperation in-progress? e.g. what will $i be:
my $i = 0;
class A { method inci() { die if $i
> It may be more useful to discuss this issue using less contrived
> examples. :)
I would agree. I haven't had any use for a double "if" or a double "for".
The double "if" case is handled by "&&". The double "for" case is handled
by "for" and "map".
The interesting cases are combinations of "
On Wed, Oct 04, 2006 at 12:50:16AM -0700, chromatic wrote:
> On Tuesday 03 October 2006 10:06, Aaron Sherman wrote:
>
> > Would there be such tools used in the core libraries? Maybe, maybe not,
> > we could discuss that. If they were implemented in the core libraries
> > would there be a univer
On 10/4/06, Juerd <[EMAIL PROTECTED]> wrote:
Damian Conway skribis 2006-10-03 16:40 (-0700):
> >Which can also be written as:
> >do { do { say 1 if 1 } if 1 } if 1;
> Sorry, no it can't. From S4
> (http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
>"Unlike in Perl 5
In a message dated Wed, 4 Oct 2006, chromatic writes:
The assumption I remember from the design meetings was always "No library
designer has the knowledge or the right to tell me how fast or strict my
program has to run." Whatever B&D you do in the privacy of your own modules
is fine, but if it
Damian Conway skribis 2006-10-03 16:40 (-0700):
> >Which can also be written as:
> >do { do { say 1 if 1 } if 1 } if 1;
> Sorry, no it can't. From S4
> (http://dev.perl.org/perl6/doc/design/syn/S04.html#The_repeat_statement):
>"Unlike in Perl 5, applying a statement modifier to a do block i
On 10/3/06, Aaron Sherman <[EMAIL PROTECTED]> wrote:
Paul Seamons wrote:
>> It relates to some old problems in the early part of the RFC/Apocalypse
>> process, and the fact that:
>>
>> say $_ for 1..10 for 1..10
>>
>> Was ambiguous. The bottom line was that you needed to define your
>> param
On Tuesday 03 October 2006 10:06, Aaron Sherman wrote:
> Would there be such tools used in the core libraries? Maybe, maybe not,
> we could discuss that. If they were implemented in the core libraries
> would there be a universal "no bondage" flag that shut them off?
> Probably, since that's somet
In a message dated Sun, 1 Oct 2006, Aaron Sherman writes:
Trey Harris wrote:
In a message dated Fri, 29 Sep 2006, Aaron Sherman writes:
[snip]
However, that's not to say that a class can't be abstract, just that a
class that does an interface (a role with nothing but abstract methods)
must im
25 matches
Mail list logo
