Re: Accessor methods ?
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 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 = $newbaz }
>
> Of course, there would need to be some way of simultaneously preventing the
> automagic creation of accessors. That might be manual:
>
> class Foo {
> my $.bar;
> my $.baz;
>
> method bar is private {}
> method baz is private {}
> ...
> }
>
> or per-attribute:
>
> class Foo {
> my $.bar is accessorless;
> my $.baz is accessorless;
> ...
> }
>
> or (my favorite) global:
>
> class Foo {
> no accessors;
>
> my $.bar;
> my $.baz;
> ...
> }
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, if/when Perl 6 gets macros...)
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Accessor methods ?
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:
> >
> > 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 = $newbaz }
Wouldn't those be the same? ".bar" is the auto-created accessor for
"$.bar", so they should do the same thing, no?
And in the case of ".baz", I'm assuming that a public member will be
given an "is rw" accessor, so that ".baz = $newbaz" will work the same
as "$.baz = $newbaz".
Granted, I use "sub" instead of "method"... that's going to take some
getting used to, but I suppose it makes sense.
Re: Accessor methods ?
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 like the following?
method set_baz(type($.baz) $newbaz) { $.baz = $newbaz }
Which would force the new value to be of the same type as the current
value, without having to strongly declare the type of the variable
elsewhere. Sort of like, in Perl5...
sub set_baz {
my $self = shift;
if (@_) {
my $new_baz = shift;
$new_baz_type = ref($new_baz) || "SCALAR";
$current_baz_type = ref($self->{baz}) || "SCALAR";
$self->{baz} = new_baz if $new_baz_type eq $current_baz_type;
}
return $self->{baz};
}
or in Eiffel...
set_baz(new_baz: like baz) is
do
baz := new_baz
end
Re: Loop controls
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 times but the variable only gets declared
once". It makes sense to declare a variable many times when it gets a
fresh, new block for each declaration, like when it's inside a loop, but to
use it in a statement that is run many times but declares the var only once
seems like it ought to throw a warning about declaring the same variable in
the same scope multiple times.
> use warnings 'P52P6';
>
> that would point out potential problems like this.
Cool idea.
-Miko
Re: Accessor methods ?
>(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 assignment operator is quite clear, and so there is no need for individual method calls for retrieving and setting the attribute. Will this exist in Perl 6? In fact, as long as we're mulling over it, will subroutine attributes be supported in Perl 6 and what kind of changes should we expect? -Erik Harrison Is your boss reading your email? Probably Keep your messages private by using Lycos Mail. Sign up today at http://mail.lycos.com
Re: Loop controls
"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 all. Essentially it's saying
> "the statement gets run many times but the variable only gets declared
> once". It makes sense to declare a variable many times when it gets a
> fresh, new block for each declaration, like when it's inside a loop, but to
> use it in a statement that is run many times but declares the var only once
> seems like it ought to throw a warning about declaring the same variable in
> the same scope multiple times.
Yeah, but declaration happens at compile time, not runtime so there's
no problem.
Minor syntax quibble, it should in fact be:
while (my $res = $search.getnext) { ... }
Or, for shiny collection modification fun:
while (my $res := $search.getnext) { ... }
--
Piers
"It is a truth universally acknowledged that a language in
possession of a rich syntax must be in need of a rewrite."
-- Jane Austen?
Re: Accessor methods ?
>
> 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, if/when Perl 6 gets macros...)
I suspect that there might be a module that would allow you to change how
Perl 6 autogenerates attribute accessors.
Damian
Re: Accessor methods ?
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 = $newbaz }
>
> 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.
> ".bar" is the auto-created accessor for
> "$.bar", so they should do the same thing, no?
Presumably, but perhaps not quite as fast.
> And in the case of ".baz", I'm assuming that a public member will be
> given an "is rw" accessor, so that ".baz = $newbaz" will work the same
> as "$.baz = $newbaz".
That would be the plan, yes.
Damian
Re: Accessor methods ?
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 get_baz() { $.baz }
>> > method set_baz($newbaz) { $.baz = $newbaz }
>>
>> 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.
>
>> ".bar" is the auto-created accessor for
>> "$.bar", so they should do the same thing, no?
>
>Presumably, but perhaps not quite as fast.
Right. I expect the method-style accessor to be slightly slower in
most cases. It may perhaps be optimized away in some cases, but I
wouldn't expect it, generally speaking.
--
Dan
--"it's like this"---
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
Re: Accessor methods ?
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 proposal seems very perlish to me
so I would hope so.
Of course, this would imply that C was an compile-time function, which
doesn't sit well with Perl's predominantly run-time typing. So it would seem
likely that there would need to be both compile-time and run-time versions
of C, or at least distinct compile-time and run-time semantics.
In which case one might need to write:
method set_baz(BEGIN{type($.baz)} $newbaz) { $.baz = $newbaz }
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 }
Hmmm.
Damian
Re: Accessor methods ?
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 setting the attribute. > Will this exist in Perl 6? Yes. The attribute C<:lvalue> will become the property C. > In fact, as long as we're mulling over it, will subroutine attributes be > supported in Perl 6 Yes. Except they'll be called properties. See: http://dev.perl.org/perl6/apocalypse/2#properties http://dev.perl.org/perl6/exegesis/2 > and what kind of changes should we expect? Slightly different syntax. More easily user-configurable. More tightly integrated with the core language. Greater variety of standard properties available. Damian
RE: Accessor methods ?
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.
Re: Accessor methods ?
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 message.
$newbaz is like($.baz), I would think, would have to raise a run-time
exception if $newbaz isn't "like" $.baz. Where would the exception be
handled, though? Inside the method/subroutine, or outside of its scope?
stringification of objects, subroutine refs
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 work around, having all of these as holes would be too much IMO.
Ed
Re: stringification of objects, subroutine refs
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 originally was, complete with variables, methods, attributes, and whatnot. How much gets serialized depends on what you'll choose--in the worst case, your entire program will need to get serialized, but that'll be doable. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
