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

[Gunther B. <gu...@ex...>]

I think that I prefer the 2nd strategy first. It is possible that it is 
necessary to go back and recode to support inheritence. However, there is 
something that has been overlooked here.

Inheritence is probably not the way most people will deal with widgets. I 
would posit based on my prior experience is most cases of widget reuse 
involves a has-a rather than is-a relationship -- a containment issue.

So if I write a DateTime widget, it would have a date widget and a time 
widget but usually not inheriting from Date widget and then adding Time 
functionality.

Of course, there are cases where inheritence is useful. I am not saying 
they don't exist. But in my experience with writing widgets for JSPs, I 
have almost never had to resort to inheritance.

At 12:25 PM 6/5/2001 -0700, ja...@la... wrote:
>Great - and you are absolutely right about the two camps for 
>implementation. In my work I took the 2nd strategy initially and ended up 
>going back and redoing that code to use accessor methods anyway.
>
>By using accessors at all times you are going to allow people like me to 
>override data type declarations with what I want but support Gunther's 
>wish for total simplicity of implementation.
>
>I do accept that there is a performance tradeoff.* Perhaps, before getting 
>too excited about performan implications we might choose to benchmark 
>this. How you implement it will affect the performance. (ie/ using 
>AUTOLOAD could be done slow - but creating closures can make it fast.) 
>Also - by itemizing the list of possible keys upfront can you not open to 
>the possiblity of a pseudohash which is faster and more compact that 
>standard hashes?
>
>Jay
>
>* I remember Stephen's statement of flexibility over performance!
>
>On Tue, 05 June 2001, Stephen Adkins wrote:
>
> >
> > 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
> > >
>
>
>
>_______________________________________________
>Perl-widget-developer mailing list
>Per...@li...
>http://lists.sourceforge.net/lists/listinfo/perl-widget-developer

__________________________________________________
Gunther Birznieks (gun...@eX...)
eXtropia - The Open Web Technology Company
http://www.eXtropia.com/