On Mon, 2002-05-20 at 00:27, Larry Wall wrote:
Aaron Sherman writes:
: Alternately, I think we should be able to mark subs as 'final' or 'inline'
: to indicate our guarantee that they won't be modified. Of course, it'll
: conflict with auto memoizing or auto currying modules that'd want to
On 5/21/02 9:56 AM, Aaron Sherman [EMAIL PROTECTED] claimed:
I guess the run-time checks will be required, and inlining of small
chunks of code will never really be all that useful (as you cannot rip
open that scope and optimize the whole context).
I think that a number of these issues of
Aaron Sherman writes:
: Alternately, I think we should be able to mark subs as 'final' or 'inline'
: to indicate our guarantee that they won't be modified. Of course, it'll
: conflict with auto memoizing or auto currying modules that'd want to
: override it, but that's their fault. :)
:
:
On Thu, 2002-05-16 at 16:07, Mike Lambert wrote:
Languages like perl can't easily be inlined, since subs may be
redefined at any time. If a sub's a leaf sub you can detect changes
before calling safely, but if it's not a leaf sub you run into the
potential issue of having the sub
At 06:11 PM 5/16/2002 -0400, Aaron Sherman wrote:
On Thu, 2002-05-16 at 16:07, Mike Lambert wrote:
There're three stages:
1. compile time -- When a module or program is byte-coded
2. load time -- When byte-code is loaded off of disk
3. run time -- When the program
On Sat, 2002-05-11 at 17:43, Damian Conway wrote:
Paul Johnson wrote:
I've always found the word like to be very wishy-washy in a computer
langauge. In what way is newbaz like baz? And just how alike are they?
There must be a better way to describe this.
Perhaps:
method
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
Wouldn't those be the same?
Not quite. C$.bar is a direct access to the attribute. C.bar is a call
to the accessor. There might well be performance issues.
I would expect that there won't be, but perhaps I'm optimistically
over-hyping
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
Wouldn't those be the same?
Not quite. C$.bar is a direct access to the attribute. C.bar is a call
to the accessor. There might well be performance issues.
I would expect that there won't
On Wed, 2002-05-15 at 10:36, Dan Sugalski wrote:
At 10:04 AM -0400 5/15/02, Aaron Sherman wrote:
On Fri, 2002-05-10 at 21:42, Damian Conway wrote:
Wouldn't those be the same?
Not quite. C$.bar is a direct access to the attribute. C.bar is a call
to the accessor. There might well
On Sun, May 12, 2002 at 12:30:20AM +0200, Pixel wrote:
FYI Ruby has:
a.type = b.type or a.type == b.type
where the various operators (, , ==, != ...) are overloaded
according to the subtyping relation.
as for me,
- i find the == very readable,
- but i'm not sure = is very
Mark J. Reed [EMAIL PROTECTED] writes:
On Sun, May 12, 2002 at 12:30:20AM +0200, Pixel wrote:
FYI Ruby has:
a.type = b.type or a.type == b.type
[...]
Well, it comes from set notation - and you used the prefixes 'sub' and
'super' exactly as they are used in sets. :)
[...]
On Fri, May 10, 2002 at 11:27:53PM -0400, Chris Dutton wrote:
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
On 5/11/02 2:43 PM, Damian Conway [EMAIL PROTECTED] claimed:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I like the latter best -- and it beats the hell out of instanceof ;-)
Regards,
David
--
David Wheeler
David Wheeler [EMAIL PROTECTED] writes:
On 5/11/02 2:43 PM, Damian Conway [EMAIL PROTECTED] claimed:
method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I like the latter best -- and it beats the hell out of
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:
sub
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 them as such:
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 something
(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
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,
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_baz($newbaz) { $.baz =
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() { $.bar }
method
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
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 and
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.
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 the
On Thu, 2002-05-09 at 12:37, David Wheeler wrote:
On 5/8/02 1:24 PM, Damian Conway [EMAIL PROTECTED] claimed:
Yes.
If you write:
class Foo {
my $.bar;
my $.baz is public;
...
}
you get a private C.bar() accessor and a public C.baz accessor.
What if I want my
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:
sub get_bar() { .bar }
sub get_baz() { .baz }
27 matches
Mail list logo
