AUTOLOAD

[Uri Guttman]

>>>>> "TS" == Tim Sweetman <ti at lemonia.org> writes:

  TS> Damian's "Best Practices" say: don't use AUTOLOAD.

  TS> I never use it, and recommend people against its use, because once
  TS> inheritance and cans are in the mix, the situation becomes extremely
  TS> unclear.

i tend to not use AUTOLOAD but then i also am not a major use of
inheritance either. i like delegation better. i do use can some but not
in the typical way. in my world objects own objects but rarely are
variants of other objects. i don't see a hierarchy of things all the
time and that view seems to rarely map onto reality. the worse is
when i see too many classes and subclasses which gain nothing but
clutter because the coder thinks inheritance is a hammer. i have taught
coders that a main object can use plain old hashes to manage subsections
and each one doesn't need a class of its own. those private subclasses
are never seem to be reused, shared, inherited, polymorphic or any other
OO thing but the coder was blindly making subclasses and classes all
over the place. it actually caused much more work in one project since
the main object and its subsections couldn't directly access much of its
own data without tons of accessors and the like. bloat, clutter, slow
code ruled. i helped him strip out the cruft and it became a better main
class for the effort. KISS applies to OO as well (don't tell that to OO
purists, they don't get it).

uri

-- 
Uri Guttman  ------  uri at stemsystems.com  -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs  ----------------------------  http://jobs.perl.org