in reply to OO style question: how much information to hide?

Seeing as how only start tags can have attributes [*], i think that the latter is more representative of the 'real world'. However, since this is a "Simple" module, then perhaps it would possible to check if $self really is a start tag inside of del_attr() and gracefully return if it is not? It could be a simple matter of performing that if statement for the client, which is nice as long as the client doesn't need to "grab a hook", which i don't think they will.

In conclusion ... i say take care of it for the client, simply because the name is HTML::TokePaser::Simple.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)
  • Comment on (jeffa) Re: OO style question: how much information to hide?

Replies are listed 'Best First'.
Re: (jeffa) Re: OO style question: how much information to hide?
by halley (Prior) on Jun 11, 2003 at 13:40 UTC

    Hear, hear. Simple interfaces should ascribe to the Perl philosophy of DWIM. If a sensible user would say, "well, duh, of course I can't delete attrs from end tags, because they don't have any," then the module should just shield the user from this aggravation. Check for end-tags inside the appropriate *_attr calls and return undef.

    Since there's no data loss in deleting what's never there (and could never be there), just ignore it. I'd say the same thing of attaching data to things which can't accept attachments (attrs on end tags), though I might suggest that such a call return undef on failure and non-undef on success. The quietest possible error.

    If the user chooses a lint/debugging mode for the object or package, then you could carp a warning. But simple interfaces should say "no harm, no foul" to irrelevant calls.

    --
    [ e d @ h a l l e y . c c ]

[reply]

      Amen++

      Though I'd like to here why you say "simple interfaces"?

      My first reaction is that all interfaces should be simple, but realistically that is always possible.

      Second thought was that in the interface is already complicated, then wheres the mileage in further complicating it by add extra methods that the caller has to use to test for stuff that can be tested internally just to avoid abending for a error that isn't?

      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "When I'm working on a problem, I never think about beauty. I think only how to solve the problem. But when I have finished, if the solution is not beautiful, I know it is wrong." -Richard Buckminster Fuller


[reply]

In Section Seekers of Perl Wisdom