At 8:58 PM -0700 5/10/02, [EMAIL PROTECTED] wrote:
>I was wondering how perl6 would stringify (as in Data::Dumper):
That's not stringification. It's serialization, which is a different
thing entirely.
What you'll potentially get is a thing that can be completely
reconstituted into what it orig
I was wondering how perl6 would stringify (as in Data::Dumper):
1) objects with 'my' and 'our' variables
2) $.property
2) subroutines (and coderefs)
3) properties (both is/has)
Right now, the fact that subroutines come out as 'sub { "DUMMY" }' is a minor
pain to w
On Friday, May 10, 2002, at 09:54 PM, Damian Conway wrote:
> That's getting a little ugly, so maybe we'd "lift" the syntax from
> Eiffel instead:
>
> method set_baz($newbaz is like($.baz)) { $.baz = $newbaz }
This is exactly what went through my mind about a half second after I
posted
Damian Conway [mailto:[EMAIL PROTECTED]] wrote:
> > ".bar" is the auto-created accessor for
> > "$.bar", so they should do the same thing, no?
>
> Presumably, but perhaps not quite as fast.
Assuming some subclass has not overridden .bar()
Dave.
Erik Steven Harrison wrote:
> I've been playing around with Perl 5.6's lvalue subs. And (though at times
> irritating to deal with) they're wonderful. It seems to me that the use of an
> assignment operator is quite clear, and so there is no need for individual method
> calls for retrieving an
Chris Dutton wrote:
> Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
> with something like the following?
>
> method set_baz(type($.baz) $newbaz) { $.baz = $newbaz }
I'm not sure that Larry has considered precisely what can be used as
a type specifier in Perl 6. Your p
At 11:42 AM +1000 5/11/02, Damian Conway wrote:
>Aaron Sherman asked:
>
>> > > sub get_bar() { .bar }
>> > > sub get_baz() { .baz }
>> > > sub set_baz($newbaz) { .baz = $newbaz }
>> >
>> >
>> > Close. They'd probably be implemented like this:
>> >
>> > method get_bar() {
Aaron Sherman asked:
> > > sub get_bar() { .bar }
> > > sub get_baz() { .baz }
> > > sub set_baz($newbaz) { .baz = $newbaz }
> >
> >
> > Close. They'd probably be implemented like this:
> >
> > method get_bar() { $.bar }
> > method get_baz() { $.baz }
> > method set_
>
> I've recently come to the conclusion that I like my get/set methods to
> look like:
>
> method foo() { $.foo }
> method set_foo($self: $new_foo) { $.foo = $new_foo; $self }
>
> (Perl6 syntax obviously). I hope it's going to be possible to set that
> up automagically... (Yeah, I know
"Miko O'Sullivan" <[EMAIL PROTECTED]> writes:
> From: "Damian Conway" <[EMAIL PROTECTED]>
>> while (my $res = $search->getnext) { ...}
>>
>> has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
>> reasonable than in Perl 5.
>
> I don't think the new meaning makes sense at al
>(Perl6 syntax obviously). I hope it's going to be possible to set that
>up automagically... (Yeah, I know, if/when Perl 6 gets macros...)
I've been playing around with Perl 5.6's lvalue subs. And (though at times irritating
to deal with) they're wonderful. It seems to me that the use of an ass
From: "Damian Conway" <[EMAIL PROTECTED]>
> while (my $res = $search->getnext) { ...}
>
> has a valid meaning in Perl 6. In fact, it's meaning in Perl 6 is far more
> reasonable than in Perl 5.
I don't think the new meaning makes sense at all. Essentially it's saying
"the statement gets run many
On Thursday, May 9, 2002, at 03:16 PM, Aaron Sherman wrote:
> Then you can declare them as such:
>
> sub get_bar() { .bar }
> sub get_baz() { .baz }
> sub set_baz($newbaz) { .baz = $newbaz }
Seeing this, an idea mildly Eiffel-ish comes to mind. Could we get away
with somethin
On Fri, 2002-05-10 at 00:27, Damian Conway wrote:
> Aaron Sherman wrote:
>
> > > What if I want my methods to be called C<.get_bar()> and C<.set_bar()>,
> > > since a certain Perl OO specialist suggests this approach is best for
> > > avoiding ambiguity in one's API?
> >
> > Then you can declare
Damian Conway <[EMAIL PROTECTED]> writes:
> Aaron Sherman wrote:
>
>> > What if I want my methods to be called C<.get_bar()> and C<.set_bar()>,
>> > since a certain Perl OO specialist suggests this approach is best for
>> > avoiding ambiguity in one's API?
>>
>> Then you can declare them as such
15 matches
Mail list logo
