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
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
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
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 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
>(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
>
> 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_
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() {
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
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
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
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
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 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
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
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
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 "<=
"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 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:
>
>
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
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 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
> 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 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
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
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 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
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
30 matches
Mail list logo
