Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

(jeffa) Re: OO style question: how much information to hide?

by jeffa (Bishop)
on Jun 11, 2003 at 03:37 UTC ( #264946=note: print w/replies, xml ) Need Help??

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.


(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 ]


      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

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://264946]
[shmem]: in the french alpes, at the end of a gravel road, we had a beer at a hut - and heard an enduro coming up.
[shmem]: not by the road, but from there below where you wouldn't want to walk.
[shmem]: the biker stopped the machine at the table and took off his helmet.
[shmem]: long white hair, long beard the same, then he proceeded to get off the bike
[shmem]: saying "biking itself isn't that much, but getting up and down - hell!"
[shmem]: up and down: on and off the bike, of course

How do I use this? | Other CB clients
Other Users?
Others lurking in the Monastery: (5)
As of 2017-06-25 20:11 GMT
Find Nodes?
    Voting Booth?
    How many monitors do you use while coding?

    Results (570 votes). Check out past polls.