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
|
