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, May 10, 2002 at 12:12:41PM -0400, Dan Sugalski wrote:
> At 5:38 PM +0200 5/10/02, Peter Gibbs wrote:
> >The result is that the last header of a COWed string will still believe that
> >the buffer is shared until a GC collection run occurs, and therefore could
> >result in buffers being copi
At 5:38 PM +0200 5/10/02, Peter Gibbs wrote:
>The result is that the last header of a COWed string will still believe that
>the buffer is shared until a GC collection run occurs, and therefore could
>result in buffers being copied unnecessarily. Your system eliminates this
>problem; however, I bel
Just set the PARROT_NO_LINE env variable to a true value. (After
syncing up CVS, of course)
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED]
At 12:29 PM -0300 5/10/02, Daniel Grunblatt wrote:
>On Fri, 10 May 2002, Aldo Calpini wrote:
> > also, to inspect core_ops.c in the debugger (instead of the not-so-helpful
> > core.ops), I had to comment all the #line directives in core_ops.c.
>I hate that too.
If you want to throw in a patch t
Hi Nicholas
The final design is now waiting on Dan, but it is always interesting to see
other ideas.
Like you, I rejected the parent/child technique. However, my proposed
solution did not use any links at all, because it relies on the garbage
collection system to determine when a shared buffer h
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
On Fri, 10 May 2002, Aldo Calpini wrote:
> it was really nice to work on it anyway. I have learned alot of things, and
> would like to suggest an 'enhancement' to Configure.pl.
>
> if the compiler is 'cl' (that is, Visual C++), and you invoke Configure.pl
> with --debugging, it should add '-DDEBU
Aldo Calpini:
# Daniel Grunblatt wrote:
# > > is anybody working on JIT-enabling the Win32 platform?
# >
# > Yes, the new JIT will work (actually, it works) on Windows,
# probably
# > you didn't read the TODO, says '(currently on hold, waiting for JIT
# > v2)', so, as soon as the the code is in
Daniel Grunblatt wrote:
> > is anybody working on JIT-enabling the Win32 platform?
>
> Yes, the new JIT will work (actually, it works) on Windows, probably you
> didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so,
> as soon as the the code is in you will be able to use the JI
On Fri, 10 May 2002, Aldo Calpini wrote:
>
> hello there (and especially the JIT team),
>
> is anybody working on JIT-enabling the Win32 platform?
Yes, the new JIT will work (actually, it works) on Windows, probably you
didn't read the TODO, says '(currently on hold, waiting for JIT v2)', so,
a
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
generat
hello there (and especially the JIT team),
is anybody working on JIT-enabling the Win32 platform?
I've done some work on this (using MASM as an assembler
and VisualC's DUMPBIN as a disassembler instead of the
GNU as and objdump).
I have a somewhat-working Parrot/Jit/MSWin32-x86.pm that
genera
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
26 matches
Mail list logo
