> 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 Pickax
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
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 compar
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.
: >
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
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
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
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
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, 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)
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
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 Documente
> 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
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
> Rejigging NCI to use the ffcall library
> Nick Glencross wondered about rejigging NCI, the parrot Native Call
> Interface to use the ffcall library. In fact he went so far as to offer
> up a proof of concept implementation. Apparently the ffcall approach
> makes it much easier to write callba
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 $
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
http://convolution
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.
> With this simple mech
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 perl
> $ 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
On Fri, 4 Nov 2005, TSa wrote:
"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
[snip]
Actually I'm not sure if Perl 6 allows
($u *= 5)++;
Since I wrote "already", I was referring to Perl5..
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 no
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
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)
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 g
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 op
26 matches
Mail list logo
