[perl6/specs] f07639: Don't use accessor methods in their own implementa...
Branch: refs/heads/master Home: https://github.com/perl6/specs Commit: f0763966964429f9bb835783635f97d6a3423c31 https://github.com/perl6/specs/commit/f0763966964429f9bb835783635f97d6a3423c31 Author: Rob Hoelz Date: 2015-01-15 (Thu, 15 Jan 2015) Changed paths: M S05-regex.pod Log Message: --- Don't use accessor methods in their own implementation &name should not be defined in terms of &name with no terminating condition
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 ?
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 ?
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 ?
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 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 ?
> 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. :) 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() } 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. :) 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. 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. :) Of course, this is all starting to impose on p6i territory. I don't like to start cross-posting unnecessarily, so someone please do that if it's appropriate. Thanks, Mike Lambert
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 C 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 ?
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 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 ?
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 ?
"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 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 ?
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: > > method set_baz($newbaz is compatible($.baz)) { $.baz = $newbaz } > method set_baz($newbaz is typeof($.baz)) { $.baz = $newbaz } 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") i prefer a.is_a?(b.type) <=> is also defined but it seems broken since it returns 1 when there is not subtyping relationship between 2 types.
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 ?
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 ?
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 } Damian
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 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 ?
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 ?
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 ?
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 ?
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 ?
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 ?
> > 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 ?
>(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 ?
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 ?
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 ?
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 ?
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
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