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
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 w
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. :)
:
:
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 p
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 p
> 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 potentially redefined while you're
> in it.
If I'm in mid
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 accesso
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 th
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-hyp
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:
>
>
"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 set
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 "<=
Damian Conway <[EMAIL PROTECTED]> writes:
> 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:
>
> meth
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 hel
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 W
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 set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz
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 }
>
> Th
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
>(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
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
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
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> access
30 matches
Mail list logo