Re: [Perl-widget-developer] Properties - object variables vs. accessors

[Stephen A. <ste...@of...>]

Hi,

Yes, we absolutely need accessors.
I recommend an AUTOLOAD method implemented on Widget::Base to
create accessors automatically (for now, anyway).

However, there are two schools of thought on use of accessors vs.
accessing the attributes directly.

 1. use accessors everywhere, even inside the class
 2. use accessors outside the class, access the attribute directly
    from within the class

I prefer #2 for performance.
Some people argue #1 so that subclasses are resilient to change in the 
superclass.  I think we just don't have a complex enough code base to
make #1 critical.  It won't be look before we finalize how to access
attributes internally.  Then it should be stable.

Stephen

At 10:22 AM 6/5/2001 -0400, Jay Lawrence wrote:
>Hey all,
>
>I was looking at the code and noticed one thing that will severely limit our
>implementation flexibility. It has to do with how properties are accessed in
>a non-abstracted fashion.
>
>When an widget is created (Widget::Base::new) you pass your properties which
>then get stuffed in the object hash for later use.
>
>OK - so you're storing properties like $widget->{'name'} = "button1". (Oh,
>BTW, shouldn't you enclose hash keys in quotes? I know it generally works
>but it generates warnings).
>
>And you're obtaining it same way ie:
>    print "My name is ".$self->{'name'};
>
>However, if you choose to have a different storage mechanism OR want to get
>fancy with how properties are resolved you need to use accessor methods. ie/
>    print "My name is ".$self->name;
>
>This way you hide the implementation of the widget (abstraction) from the
>calling routine. You actually need to use this strategy everywhere.
>
>There are a number of ways to handle this:
>    AUTOLOAD - resolve name of method to a property or raise error
>    manual accessor contruction - lots 'n lots of subs
>    automated accessor construction - 1/2 doz packages in CPAN that do the
>job
>
>I know there will be arguments of efficiency vs. flexibility but I do recall
>Stephen saying that at this stage we'll be thinking more on flexibility than
>efficiency. But down the road we might be able to trade the expense of a
>function call with a more efficient storage mechanism like pseudohashs.
>
>Jay
>
>
>
>_______________________________________________
>Perl-widget-developer mailing list
>Per...@li...
>http://lists.sourceforge.net/lists/listinfo/perl-widget-developer
>