Re: [wxperl-users] child accessors

[Eric W. <scr...@gm...>]

# from Mark Dootson
# on Saturday 17 March 2007 09:03 pm:

>I'm presently stuck with
>
>->MyGetControlMethod('controlname');
>->MyGetMenuMethod('menuname');
>
>which, of course, works and is I think at least better than
>$self->{controlname} or $self->{menuitemisaved}.

Well, I just put a WxPerl::MenuMaker in $self->mm and 
$self->{control_name} is simply $self->control_name.  If you then have 
clashing methods because of widget names, that's going to make trouble 
anyway, so I tend to see the "pass a string to a method" scheme as 
unjustified (and you have to error-check it.)

>I'm undecided on the named accessor thing. On the one hand I think
> that any accessors in your classes should behave in a standard way vs
> inheritance whether hard coded or added at runtime and if you can't
> achieve that you should leave it alone.

Well, Class::Accessor doesn't allow you to override the accessors.  It 
does allow you to override the get()/set() methods, but 
Class::Accessor::Fast loses that.  Class::Accessor::Classy lets you 
have it both ways (at least, as soon as I push the next version) by 
declaring a setter(sub {...});  Anyway, that's all overkill for simply 
preventing typo's when accessing child widgets, but inheriting a new() 
really rains on the parade if you're subclassing something besides the 
accessor generator.  If you're not making a specialized accessor 
generator, why subclass an accessor generator?

Nearly all of dotReader is done in Class::Accessor::Classy now, and I'm 
thoroughly enjoying the clean, declarative syntax since it basically 
serves as documentation where __PACKAGE__->mk_accessors("foo") won't.  
Also, the recent meta-data capturing means ./util/accessor_report can 
show me all of the attributes for a given class.

> On the other hand, accessors 
> for controls would be sooooo nice and you could always take the view
> that in practical terms, approach X does the job so lets go for it.

Yeah, '$self->that_button' does the job.

> Then again, would it be wise to implement your own scheme rather than
> the commonly used Class::Accessor with its known limitations /
> workarounds? I'm firmly on the fence today.

Uh, it's already implemented and requires no workarounds?  I might not 
be wise, I might be crazy, but I'm pretty sure I'm not delusional 
(yet :-D)

--Eric
-- 
"I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors."
--Ben Schneiderman
---------------------------------------------------
    http://scratchcomputing.com
---------------------------------------------------