On Wed, 2 Nov 2005, John Williams wrote:
surprises including operandless operators. Including mutating operandless
operators. What is s/// after all? Or is there a good reason for an
asymmetry between different classes of operators?
Well, s/// is a term, for one thing.
It is not so much an
On Wed, 2 Nov 2005, Rob Kinyon wrote:
I think the difference comes from the Principle of Least Surprise. The
various operators being discussed in this thread are all operators
which are in languages that have common use - C, C++, Java, the .Net
stack, etc. Regexen and the various built-ins are
HaloO,
Michele Dondi wrote:
And yes: there are lots of languages having (e.g.) a ++ operator, mostly
derived from C. But Perl's C++ already allows an extended syntax wrt
that of those other languages, that is: I'm not really sure, but I don't
think that in C you can do (the equivalent of)
HaloO,
Luke Palmer wrote:
Well, it's possible that I'm abusing the terms, since I first heard
the terms from you and inferred what they meant.
I'm honoured. Thanks. Please don't get me wrong. I appreciate the
document you wrote. I just want to help with peer reviewing it.
However, there is
On Thu, 20 Oct 2005, Nate Wiger wrote:
just to be sure we're on the same page: You say that the thing that
is going to hinder migration to Perl 6 is the fact that it's different
from Perl 5.
Intentionally trite oversimplification. My problem is that it's
different in some ways which are
$ perl -le '$u=1; ($y=$u*=5)++; print $y'
6
It's interesting to note that this parse (due to precedence) as
($y=($u*=5))++, not (($y=$u)*=5)++
This is important for overloaded operators (which are going to become
much easier to do in Perl6). The importance arises if Perl6 allows
assignment to
The Perl 6 Summary for the week ending 2005-10-30
Hmm... Thursday afternoon and I've only just started writing the
summary... What happened to professionalism? What happened to rigid,
albeit self-imposed deadlines?
Um... I've had a cold. The cats ate my homework.
This week in
Michele Dondi skribis 2005-11-04 14:58 (+0100):
Let me explain: we all know that Perl5 has a very simple parameter
passing mechanism for subs and an even more rudimentary
{prototyping,signature} mechanism that one actually seldom uses.
It is unused because it sucks. /blunt
With this simple
The Perl 6 Summarizer skribis 2005-11-04 14:34 (+):
$_ defaulting for mutating ops
Probably I have not been clear enough about that I no longer think this
is a good idea.
Juerd
--
http://convolution.nl/maak_juerd_blij.html
http://convolution.nl/make_juerd_happy.html
On Fri, 4 Nov 2005, Juerd wrote:
for simple subs in Perl6 I will probably still use @_
You'd be a fool to do so, with the sole exception of list manipulation,
[snip]
Compare:
sub dosomething { @_[0] blah @_[1] }
sub dosomething ($a, $b) { $a blah $b }
sub dosomething { $^a blah
On 11/4/05, Michele Dondi [EMAIL PROTECTED] wrote:
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff all
them in has brought in quite a lot
It will buy you 400% in saving typing, 4000% in less debubbing and
4% in maintainability(==readability).
I think this is the main point here. With @_ and bless() you could do
cool things, but again it happened at the expense of repetition and
all those other buzzwords (maintainability, et
Hello!
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the role, does it do the role anyway?
role
On 11/4/05, Austin Frank [EMAIL PROTECTED] wrote:
Hello!
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
On Fri, Nov 04, 2005 at 03:49:05PM +0100, Juerd wrote:
sub dosomething { $^a blah $^b }
I think the $^ variables are only allowed in bare (or -) blocks. (As a
guard against san.. er, madness.)
--
Ilmari Vacklin (wolverian)
HaloO,
Larry Wall wrote:
On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: Yeah, I didn't really follow his argument on that one. I, too, think
: that the one() junction in general is silly, especially for types.
Well, I think it's silly too. I'm just trying to see if we need to
On Fri, 2005-11-04 at 13:15 -0500, Austin Frank wrote:
If roles are interfaces, do we want any class that provides an interface
consistent with a role to implicitly do the role? That is, if a class
fulfills all of the interface requirements of a role without actually
saying it does the
Juerd [EMAIL PROTECTED] writes:
Michele Dondi skribis 2005-11-04 14:58 (+0100):
Let me explain: we all know that Perl5 has a very simple parameter
passing mechanism for subs and an even more rudimentary
{prototyping,signature} mechanism that one actually seldom uses.
It is unused because it
Rob Kinyon [EMAIL PROTECTED] writes:
On 11/4/05, Michele Dondi [EMAIL PROTECTED] wrote:
I'm still convinced my remark _partly_ applies in the sense that the
overall impression is that a vast majority of most common needs is
addressed by a *subset* of the current features and trying to stuff
On Fri, Nov 04, 2005 at 12:37:04PM +0100, TSa wrote:
: The above also describes my perception of the $. twigil notation which
: are variables bound through the invocant(s). My mental picture beeing
: one where a method is instanciated as a not yet invoked sub after selecting
: the target code body
On Fri, Nov 04, 2005 at 08:14:11PM +0100, TSa wrote:
: HaloO,
:
: Larry Wall wrote:
: On Tue, Oct 25, 2005 at 10:25:48PM -0600, Luke Palmer wrote:
: : Yeah, I didn't really follow his argument on that one. I, too, think
: : that the one() junction in general is silly, especially for types.
:
:
HaloO,
Larry Wall wrote:
On Wed, Oct 26, 2005 at 04:56:23PM -0600, Luke Palmer wrote:
: Then ^T $x binds T to the kind of $x. And $x.kind == $y.kind asks
: if two objects are of the same type,
:
: Don't you mean $x.kind eqv $y.kind?
I start to dislike the eqv name as generic value
HaloO,
Larry Wall wrote:
At the moment, I think the weakest word choice is subtype.
People from certain cultures will confuse subtypes with subclasses.
Not to mention submethods and subroutines!
The notion of constraints or limitations is already conveyed by
where, and some subtypes may
And when your user does want to, essentially say Nah, you screwed up
designing
that object protocol, children shouldn't've been protected. it's the work of
a
moment to write:
thing.send(:children, *args)
I told you I'm still learning. I hadn't gotten to that part of the Pickaxe. :-/
24 matches
Mail list logo
