On Tue, May 11, 2004 at 14:32:42 -0400, Ross McFarland wrote:
Jan Hudec said:Hello All, When subclassing a widget, it's probably not uncommon that setting or getting at least one property needs to be treated specialy, but for some other properties the default behaviour (just storing it in the hash) is ok. Or perhaps even for the special property get can do with the default implementation. Therefore I suggest following enhancement for the default SET_PROPERTY/GET_PROPERTY methods: If SET_<property-name>/GET_<property-name> method exists, it is called. Otherwise, the property is set to/retrieved from the hash. I would actualy like set_/get_ prefixes better (such methods are more suited to be called directly), but the following patch uses SET_/GET_ because that is less likely to break existing stuff.basically my question is what is insufficent/wrong about doing things like this: sub GET_PROPERTY { my ($self, $pspec) = @_; my $name = $psepc->get_name; if ($name eq 'special_case') { # whatever magic you want/need goes here return $self->GET_OTHER_PROPERTY ($psepc); } else { return $self->{$name}; } } rather than having the extra overhead of looking for the sub with the upper cased version of the property name.
There is nothing wrong with it. And if you care for overhead, it's the
way to go. And I didn't say it CAN'T be done. I just want it so that it
does not HAVE to be done.
Now, why I don't like such code:
1) It's a repetitive code. It will be the same for each subclassed
widget, except for the property names. Such code should be
autogenerated, or not needed at all.
2) The property name appears in more places than strictly necessary,
which makes it a bit more prone to error. When you change something,
you have to keep in mind where else the name appears. And, unlike C,
perl won't check for you.
3) It encourages long functions. Long functions are hard to reader to
read and harder to debug.
And one more argument is, that the current implementation is mostly
useless (properties are mostly useful exactly because they have
getter/setter). I try to make them useful for more cases.
Now, there are ways to avoid the overhead. Since the GET/SET_PROPERTY is
called for the package that defined it, it might be a function call by
name instead of method lookup. It get's down to hash lookup, which
actualy better than a long chain of ifs. We could also abuse AUTOLOAD to
create default getters/setters and always call getter/setter, but
I don't believe it will be significant.
-------------------------------------------------------------------------------
Jan 'Bulb' Hudec <bulb ucw cz>
Attachment:
signature.asc
Description: Digital signature