Re: Accessor methods ?
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
: override it, but that's their fault. :)
:
: Yes, I suggested inline or const I can't imagine that we would
: want to do without this, regardless of what we call it. Otherwise,
: auto-accessors will always be slower than using the variable. Would
: everyone agree that this property should default to being set for
: auto-accessors?
No, that would undo the whole point of making them accessors in the
first place.
Think of this like a constant variable. In Perl5, we can do:
use constant foo=1;
use constant foo=2;
and foo will have the value 2, but you cannot change the value of foo
during run-time. That's all I'm saying for accessors. This way, when I
define
class argh {
my $.foo;
}
I get
method foo() is rw($newfoo) is inline { ... }
but, in another module, there's nothing to stop you from:
method argh::foo() { die No, you don't! }
because all that matters is that AFTER perl sees you call C$obj.foo,
it never changes.
Of course, this all goes out the window if inlining happens at
compile-time, since libraries will no longer be able to override
auto-accessors later on.
: In this model, you only ever inline at load time ***OR*** when the
: compiler is attempting to produce a self-contained byte-code executable
: (e.g. one which has all of the modules in it), in which case it executes
: that part of the load time process early. If you like, call this a
: sub-stage of load time, which I shall dub link time. Link time can
: only happen once per program, so it must happen when we actually know
: what all of the program components are.
It seems like an assumption that link time can only happen once. An
incremental linker might feel like it can relink any time it feels like
it. Some very useful programs never completely know what their
components are.
Agreed, and I would be remiss if I didn't mention that all good
intentions go out the window the moment someone does:
sub mumble() is inline { ... }
eval 'use stuff;mumble()';
Now, we could have the case where mumble has been redefined, or the case
where mumble is still the old inlinable thing, but inlineables that it
calls have been redefined.
Ick, *shudder*.
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).
Re: Accessor methods ?
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 inlining methods were considered by p5p about two years ago, when Doub MacEachern submitted a patch that optimized Perl 5 method calls. Simon wrote about it here: http://www.perl.com/lpt/a/2000/06/dougpatch.html Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
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. :) : : Yes, I suggested inline or const I can't imagine that we would : want to do without this, regardless of what we call it. Otherwise, : auto-accessors will always be slower than using the variable. Would : everyone agree that this property should default to being set for : auto-accessors? No, that would undo the whole point of making them accessors in the first place. : And even though distributed .pbc files and seperate compilation are some : goals of perl6, I still think we're okay. If we inline a function in : module A, and module A changes, Perl6 should ensure that the original : version is still loaded for our code, and thus our inlining should still : be valid. : : Oh, that one's easy (I think/hope/pray). : : 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 begins to execute : : There are complexities, but you get the idea. Load time, I assume is : also when BEGIN executes. Actually, BEGIN has to execute at compile time. INIT runs between load time and run time. : In this model, you only ever inline at load time ***OR*** when the : compiler is attempting to produce a self-contained byte-code executable : (e.g. one which has all of the modules in it), in which case it executes : that part of the load time process early. If you like, call this a : sub-stage of load time, which I shall dub link time. Link time can : only happen once per program, so it must happen when we actually know : what all of the program components are. It seems like an assumption that link time can only happen once. An incremental linker might feel like it can relink any time it feels like it. Some very useful programs never completely know what their components are. : Any other way of doing this would seem to me to be a very dangerous : weapon to brandish so close to so many unsuspecting feet. :-( We've never shied away from issuing people enough rope. But I don't think that has to be the case here. We'll likely have an inline property. : Another avenue is that of self-modifying code. I know it would break : threads, or cause code duplication between threads, but when A changes, we : can either re-inline the new subroutine, or eliminate the 'if-else' check : to avoid the branch we know will be false from then on. Creating code : which optimizes itself as it's run based upon internal profiling would be : cool. But that's the topic of a different thread. :) : : Code that does this by changing sub references should still work. Code : that does this by changing its own internal representation gets what it : paid for. But methods don't have a unique sub ref until you know the type. One could inline a jump table of sub refs based on known types, and default to ordinary method lookup for unknown types. But there's no guarantee that would actually be faster than a decent vtable lookup. Larry
Re: Accessor methods ?
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 potentially redefined while you're
in it.
If I'm in middle of executing function A, and I redefine function A, then
it doesn't matter for the execution of the function. Even un-inlined, the
execution continues as it did before. Perhaps this should be an argument
to appease the callee-save proponents. Their main argument was leaf subs.
If we can guarantee that these are inlined, then their only argument goes
away. :)
Hmm... I see some conversational double-speak there, but I don't recall
the thread. Point granted.
As such, I think we should be able to inline a call to A() with:
if( value A == value of A when we inlined it )
contents of sub
} else {
A()
}
Yes, in the default case I think that's what was being discussed.
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. :)
Yes, I suggested inline or const I can't imagine that we would
want to do without this, regardless of what we call it. Otherwise,
auto-accessors will always be slower than using the variable. Would
everyone agree that this property should default to being set for
auto-accessors?
And even though distributed .pbc files and seperate compilation are some
goals of perl6, I still think we're okay. If we inline a function in
module A, and module A changes, Perl6 should ensure that the original
version is still loaded for our code, and thus our inlining should still
be valid.
Oh, that one's easy (I think/hope/pray).
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 begins to execute
There are complexities, but you get the idea. Load time, I assume is
also when BEGIN executes.
In this model, you only ever inline at load time ***OR*** when the
compiler is attempting to produce a self-contained byte-code executable
(e.g. one which has all of the modules in it), in which case it executes
that part of the load time process early. If you like, call this a
sub-stage of load time, which I shall dub link time. Link time can
only happen once per program, so it must happen when we actually know
what all of the program components are.
Any other way of doing this would seem to me to be a very dangerous
weapon to brandish so close to so many unsuspecting feet. :-(
Another avenue is that of self-modifying code. I know it would break
threads, or cause code duplication between threads, but when A changes, we
can either re-inline the new subroutine, or eliminate the 'if-else' check
to avoid the branch we know will be false from then on. Creating code
which optimizes itself as it's run based upon internal profiling would be
cool. But that's the topic of a different thread. :)
Code that does this by changing sub references should still work. Code
that does this by changing its own internal representation gets what it
paid for.
Re: Accessor methods ?
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 begins to execute There are complexities, but you get the idea. Load time, I assume is also when BEGIN executes. In this model, you only ever inline at load time ***OR*** when the compiler is attempting to produce a self-contained byte-code executable I don't think load time inlining is going to be within Parrot's spec. -Melvin
Re: Accessor methods ?
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 set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz }
method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz }
I don't like the second one, as it implies that Perl has types, which it
really doesn't (properties are just that, properties).
The first is a bit long, but I could get behind it in a crunch.
However, my first thought is, why do we need a keyword here?
Since it's not otherwise valid syntax (the semi-unofficial battle-cry of
perl6-language ;-), I propose:
method set_baz($newbaz is $.baz) { .baz = $newbaz }
There's two ways to take C$x is $y. I think it's easy enough to get
people used to the idea that aliases are created vi C:=, so there's
really only one left.
And, yes I do think that using the auto-accessor is more correct. It
should be in-lined under most circumstances, but if someone comes along
later and moves that accessor into a super-class, we're still good.
Re: Accessor methods ?
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 Perl6's inlining before it exists. Surely, we would always prefer that every method except accessors use the accessors, though. After all, later modification of the class might move the member variables to a super-class.
Re: Accessor methods ?
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 be, but perhaps I'm optimistically over-hyping Perl6's inlining before it exists. 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. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: Accessor methods ?
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 be performance issues.
I would expect that there won't be, but perhaps I'm optimistically
over-hyping Perl6's inlining before it exists.
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.
That seems like a tragic performance-sink Is there some way that the
caller and/or function could indicate that they want to avoid such
over-generalization? Something like an is const or is inline to
indicate that the subroutine is read-only and cannot be redefined?
When the parser sees:
sub subname(...) is inline { ... }
subname(...);
It could safely just inline the code without any sort of run-time check.
Normal inlining would still take a hit, but I'd hate to see:
$minusone = E ** (PI * I)
go through a run-time check for redefinition.
Of course, we're talking run-time. If you use two modules which both
define a common subroutine as inline (or only one does), there should be
no conflict and the second should override the first. It's only run-time
redefinition of a subroutine which would prevent efficient inlining.
So, in my example above, you could still Cuse Math::Pi::Simple to get
the version of PI that's defined as 3, but you could not have a
subroutine that swapped PI between the two values, based on a
command-line flag.
Re: Accessor methods ?
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 readable (who knows that a supertype is greater, and a subtype is smaller) Well, it comes from set notation - and you used the prefixes 'sub' and 'super' exactly as they are used in sets. :) The = is an ASCIIfication of the is a subset of operator (also used as such in, e.g., Pascal). The real operator, U+2286, uses a 'U' rotated 90 degrees clockwise in place of the '' symbol, and - like the real mathematical symbol for less than or equal - has a line underneath that symbol instead of an '=' next to it. Anyway, if you regard a class as the set of objects which can be treated as instances of that class, then use of a Rubylike notation (and the terms 'subclass' and 'superclass') follows logically. -- Mark REED| CNN Internet Technology 1 CNN Center Rm SW0831G | [EMAIL PROTECTED] Atlanta, GA 30348 USA | +1 404 827 4754 -- FORTRAN is not a flower but a weed -- it is hardy, occasionally blooms, and grows in every computer. -- A.J. Perlis
Re: Accessor methods ?
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. :) [...] Anyway, if you regard a class as the set of objects which can be treated as instances of that class, then use of a Rubylike notation (and the terms 'subclass' and 'superclass') follows logically. i do understand this notation [*], but i don't know if it's *readable*. many people prefer: a.isa(b.type) by the way, this notation seems to come from smalltalk. and = on incompatible types now return an exception in Ruby 1.7 [*] i'm trying to develop a programming language (merd) which is very based on subtyping/supertying. -- Pixel http://merd.net merd = Perl-Python-Ruby-alike expressivity + static type checks (a la Haskell)
Re: Accessor methods ?
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 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.
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.
--
Paul Johnson - [EMAIL PROTECTED]
http://www.pjcj.net
Re: Accessor methods ?
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 AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/ Yahoo!: dew7e
Jabber: [EMAIL PROTECTED]
Re: Accessor methods ?
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 instanceof ;-)
talking about instanceof, here are the various syntaxes:
* testing class membership
x isax Perl x
x is_a? kind_of? x Ruby x
x dynamic_cast x C++ x
x instanceof x Java x
x isinstance x Python x
x in x Ada x
x is x C# x
x is_a x PHP x
x entry_type x Pliant x
x ISTYPE x Modula-3 x
x object## classname## x Beta x
x var ?= val (20)x Eiffel x
* get the class corresponding to an object/instance
x type x Ruby x
x __class__ x Python x
x getClass x Java x
x typeidx C++x
if you know some more, tell me :)
http://merd.net/pixel/language-study/syntax-across-languages.html
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: 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: 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 Ctype 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 Ctype, 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 Cis rw. 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?
Re: Accessor methods ?
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 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 }
I suppose there could be some magic like:
class Foo is accessedby('get_','','r')
is accessedby('set_','','rw') { ... }
To declare that Foo has accessors with prefix get_ and no suffix for
read-only acces and prefix set_ and no suffix for read/write access.
But, I'm not sure how valuable this would be
Re: Accessor methods ?
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;
...
}
Damian
I suppose there could be some magic like:
class Foo is accessedby('get_','','r')
is accessedby('set_','','rw') { ... }
To declare that Foo has accessors with prefix get_ and no suffix for
read-only acces and prefix set_ and no suffix for read/write access.
But, I'm not sure how valuable this would be
