Re: Is there always MTOWTDI?

The apprentice, noting his name taken in vain, hazards this reply...

A qualified yes...

As with Perl itself, doesn't the real answer depend on the specific context? We saw three (or four, depending on who's counting) different ways to tackle the problem. I admit, your approach best fit the actual context. I can imagine other contexts where the other approaches might offer advantages.

Certainly it makes sense to use a module's error handling facilities when possible. However, my work with the Windows API (yes, I know it sucks, but there you are.) suggests that there are times when a selective use of a library's features can provide more than the original designer thought could (or should) be made made available (or documented).

That suggests, of course, a certain level of familiarity of said API...and a certain level of mastery over the implementation. Not to mention (something us Win folk are still amazed at), access to source (or, as is more common for us, access to definitions via header files).

In turn, it suggests that unless you feel confident that you have said familiarity, you should defer to the module's author, as that's really the whole point of modules. Isn't it? Follow another, more experienced person's footsteps to benefit from their experience, knowlege, and agony?

And, should you choose to break the rules *or* do something really tricky, please, please, oh *PLEASE* document it in comments so lesser mortals can see (and follow) your wisdom...

--f

P.S. Sorry...that's a sore spot at the moment. It'll heal; promise...

Comment on Re: Is there always MTOWTDI?

Replies are listed 'Best First'.
Re (tilly) 2: Is there always MTOWTDI? by tilly (Archbishop) on Dec 20, 2000 at 20:46 UTC
Be very, very careful. Relying on the details of someone else's implementation is a very bad thing to do. Oh, lots of people do it. It works. But it leads to extra complexity, potential problems with future changes to the library, etc, etc, etc. In general assume that anything not explicitly documented can and will change. Work with the interface whereever possible. Anything which pokes around in internals you have no business accessing should be regarded as probable future breakage. And remember that modular code is broken into components, each of which has a simple interface to the outside world. Keep your interfaces simple and clean, only use those interfaces. you will save a lot of headaches...	[reply]
Re: Re: Is there always MTOWTDI? by PsychoSpunk (Hermit) on Dec 20, 2000 at 22:24 UTC
footpad, in the case of the Windows API, you suggest selective use of the library's features. But unless you are writing your own interfaces to access the internals, you're still playing by the rules. I would wager that you still have to use the interfaces to get at the internal data, but you do so in unique ways in which the developer didn't imagine. That's the job of a developer. Provide all the methods that are necessary to get to the needed information, but as the developer you can never know how this is going to be used. This is the human side of encapsulation, often seen in the situation where the manager hands you a ream of paper and says, "Do this." You just do it, without knowing who's going to do what with it. Of course, this is an extreme model, but it happens. My big point is that unlike a real OO language (touchy subject I know, but in a comparative sense), Perl doesn't hold these restrictions over our head when it's running a script. We have to take charge and hold these restrictions on ourselves if we choose to develop with a certain API. tilly may have pointed out the best reason why, even though it's unlikely that certain actions (such as our lovely RaiseError producing warnings) will change, we can't assume that they won't. ALL HAIL BRAK!!!	[reply]