http://qs1969.pair.com?node_id=342904


in reply to Re: Re: Why breaking can() is acceptable
in thread Why breaking can() is acceptable

The following snippet is taken from that example I alluded to above.
# This exists to provide object-specific can() functionality. # 1) If this is an object, check to see if the method is an element na +me. # 2) If either is not true, redispatch to the parent's can() method. + sub can { ( ref($_[0]) && UNIVERSAL::isa( $_[0]->elements, 'HASH' ) && exists $_[0]->elements->{$_[1]} ) || ( $_[0]->SUPER::can($_[1]) ); } sub AUTOLOAD { (my $name = our $AUTOLOAD) =~ s/.*::([^:]+)$/$1/; my $self = shift; unless ($name eq lc $name || exists $self->element_classes->{lc $n +ame}) { return eval "$self->SUPER::$meth(@_);"; } $self->elements->{$name} = shift if @_; $self->elements->{$name}; }

A few notes:

  1. This is a container object, providing a unified interface to parsing stuff. It acts as a record and the elements are the various columns. Each record may have different columns and the goal was to provide a way of allowing the user to call the column name as a method and get the column object.
  2. element_classes is a method which returns a hashref of name-class pairs. The name is the name of the column as provided to this object in the constructor. The class is the class of the column.
  3. elements is a hashref which actually contains the column objects in name-object pairs. It is guaranteed that the names from element_classes() will be identical to the names from elements().

This implementation has the added benefit of the fact that it's currently working in production. Now, nothing inherits from it (yet) and I do not use MI in production code, for the reasons well-cited elsewhere.

------
We are the carpenters and bricklayers of the Information Age.

Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose