Re: Name space: throwing exceptions easily
* On Wed, Jul 02 2008, Aristotle Pagaltzis wrote: On this, I disagree. Here’s litmus test: would you ever use the opposite adjective in a description? If not, it’s not useful. I think you’ll agree that no one would call a module Exception::Complicated except as a joke. That means “easy” provides no useful differentiation in practice. I don't think this tests what you think it tests. People don't name their module Foo::Complicated because they don't want to admit the interface is complicated. People *do* call modules Foo::Easy because they're proud that they made Foo easy. So the module naming here reflects the author's personal or societal hangups, not the validity of any naming scheme. In fact, the “simplified” in “simplified interface” is largely redundant. Using an interface by definition means you are looking for simplification in doing or accessing the thing that the interface provides. Easy means less features to learn. Ever use XML::LibXML? It's big. It's hard to get started with it. If you just wanted to XPath some XML string, you might like a module like XML::LibXML::Easy to exists. Instead of creating a parser, parsing a balanced chunk into a document fragment, initializing the XPath engine, adding some namespace, running the query, and then printing the returned nodes; you might just want to say 'xml(foo)-xpath(//foo)-stringify'. That's not nearly as complex as XML::LibXML, so why not call it Easy? Of course, you lose a lot of power with that API. Tradeoffs. Similar words that say something without communicating anything are “fast” and “flexible.” No one would say that they are trying to achieve slowness or inflexibility. Usually the slow/inflexible version comes first, so it gets the base namespace. If history could be rewritten, then the slow version would be replaced with the fast one... but that's not always possible, especially with how CPAN.pm works. Basically, the names of CPAN modules are hacks around CPAN itself. I see a trend here… you are the person who argued loudly that in the end, anyone who wants to know how Catalyst works needs to read the code, regardless of the state of the docs… I'm not sure why this upsets so many people. If you want a complete understanding of every detail of a codebase, you have to read it. You're not going to get any better at programming if you never read code. This is what I believe and I'm going to stand by it. (If you don't want to be good at programming, that's fine with me. Give me some money and I can solve your programming problems for you :P) Anyway... if you don't want to read the code, I hear there's a whole book about Catalyst. Then again, you are the author of a Catalyst-based weblog app called Angerwhale, which makes me wonder if you haven’t long forfeited your right to take part in *any* discussion about naming. :-P Modules and applications have different naming standards. I think most of my modules have names that make sense. I can't think of any applications I use that have names that make sense, however. emacs for editing text? amarok for playing music? urxvt for emulating terminals? irssi for chat? None of those names make any sense at all. So I don't feel like I'm alone in coming up with weird-ass names for things :) Names for modules need to be somewhat related to what they do, but you probably shouldn't devote too much mental energy to coming up with a name. It's just not *that* important. (Opaque identifiers)++ Regards, Jonathan Rockway -- print just = another = perl = hacker = if $,=$
Re: Name space: throwing exceptions easily
* Jonathan Rockway [EMAIL PROTECTED] [2008-07-03 19:35]: Of course, you lose a lot of power with that API. Tradeoffs. Which is, as I said, what you want to communicate. So I don't feel like I'm alone in coming up with weird-ass names for things :) That was tongue-in-cheek anyway, hence the razz smiley. :-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
* Jonathan Rockway [EMAIL PROTECTED] [2008-07-02 18:30]: * On Tue, Jul 01 2008, Aristotle Pagaltzis wrote: If I see a module called Exception::Easy in a list of modules, I have *absolutely no idea* what it does. In contrast, if it was Exception::Class::Functions, I could immediately guess pretty well at what it does, even if I didn’t know exactly. I take it the opposite way. Exception::Class::Functions makes no sense to me. Class? Functions? What? In the end, I will have to click through and read the docs. The name is meaningless and hard to type. Fair enough. We can reasonably disagree on whether Exception::Class::Functions is a good name. That’s neither here nor there. Personally I don’t like it a lot, just better than the other options on the table so far. As for Exception::Easy, I think that makes a lot of sense. Oh hey, a simplified interface for dealing with exceptions. I will still have to click through and read the docs, though. On this, I disagree. Here’s litmus test: would you ever use the opposite adjective in a description? If not, it’s not useful. I think you’ll agree that no one would call a module Exception::Complicated except as a joke. That means “easy” provides no useful differentiation in practice. In fact, the “simplified” in “simplified interface” is largely redundant. Using an interface by definition means you are looking for simplification in doing or accessing the thing that the interface provides. Similar words that say something without communicating anything are “fast” and “flexible.” No one would say that they are trying to achieve slowness or inflexibility. In all of these cases, there is a tradeoff that you are accepting to gain, say, simplicity at the cost of inflexibility, or maybe flexibility at the cost of simplicity, or flexibility and simplicity both at the cost of performance, or whatever the particular tradeoff happens to be. Additionally, Exception::Easy will only show up when searching for exception, while Exception::Class::Functions will show up when searching for class and function in addition to exception. Exception is really the only relevant keyword, so why contaminate the already-busy Class search with something that's not relevant? Because anyone who searches on “class” gets what they deserve. :-) In the end, I can't think of any module names that make sense without knowing what they are. A few words aren't enough to describe a module in detail. If you are faced with 10 search results that sound relevant, you will just have to click through and skim the docs. Even if the module does what you want, the interface might not be what you want, or you might dislike the implementation. I see a trend here… you are the person who argued loudly that in the end, anyone who wants to know how Catalyst works needs to read the code, regardless of the state of the docs… I think Shakespeare said it best: What's in a name? that which we call a rose By any other name would smell as sweet; The converse is also true. Whoohoo, let’s just call it NinjaCamp then (it produces functions that throw fatal errors, geddit, geddit?). Naming is hard, let’s go shopping. Maybe you want to (re-?)read Zen of Comprehensive Archive Networks sometime. Then again, you are the author of a Catalyst-based weblog app called Angerwhale, which makes me wonder if you haven’t long forfeited your right to take part in *any* discussion about naming. :-P Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
* Aristotle Pagaltzis [EMAIL PROTECTED] [2008-07-03 00:25]: In fact, the “simplified” in “simplified interface” is largely redundant. Using an interface by definition means you are looking for simplification in doing or accessing the thing that the interface provides. Similar words that say something without communicating anything are “fast” and “flexible.” No one would say that they are trying to achieve slowness or inflexibility. In all of these cases, there is a tradeoff that you are accepting to gain, say, simplicity at the cost of inflexibility, or maybe flexibility at the cost of simplicity, or flexibility and simplicity both at the cost of performance, or whatever the particular tradeoff happens to be. Err, I forgot to finish my argument. Where I was going with this is that it is this tradeoff that is meaningful, and that is what you want to describe in a summary such as the name of a module. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
# from Aristotle Pagaltzis # on Wednesday 02 July 2008 15:21: no one would call a module Exception::Complicated except as a joke. Well, you're going to have a hard time predicting what a gaggle of zany programmers might do, especially if you dare them like that ;-) I, for one, am seriously looking forward to the opportunity to publish Exception::Complicated::Er. That means “easy” provides no useful differentiation in practice. That much is true. Except it does imply that the author thought something about the problem space was overly difficult, which might resonate with the audience. Whoohoo, let’s just call it NinjaCamp then That's a snazzy name, but doesn't really fit since ninjas might conjure up associations such as sneaky assassins for hire -- I would like my exceptions to be more straightforward and loyal. Possibly Samurai::Picnic or Berserker::Expedition. Or just Grenadier. --Eric -- Don't worry about what anybody else is going to do. The best way to predict the future is to invent it. --Alan Kay --- http://scratchcomputing.com ---
Re: Name space: throwing exceptions easily
* Eric Wilhelm [EMAIL PROTECTED] [2008-07-03 02:00]: # from Aristotle Pagaltzis # on Wednesday 02 July 2008 15:21: no one would call a module Exception::Complicated except as a joke. Well, you're going to have a hard time predicting what a gaggle of zany programmers might do, especially if you dare them like that ;-) I, for one, am seriously looking forward to the opportunity to publish Exception::Complicated::Er. That’s the “as a joke” clause. I made very sure not to forget that qualification. ;-) Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
On Wed, Jul 2, 2008 at 5:44 PM, Aristotle Pagaltzis [EMAIL PROTECTED] wrote: * Aristotle Pagaltzis [EMAIL PROTECTED] [2008-07-03 00:25]: No one would say that they are trying to achieve slowness or inflexibility. Drafted any mission-critical change control policies recently?
Re: Name space: throwing exceptions easily
* sawyer x [EMAIL PROTECTED] [2008-07-01 08:10]: personally I find ::Easy and ::Simple no more useful than ::Foo. It says absolutely nothing about what kind of ease or simplicity I can expect, and CPAN has plenty of examples of such modules exhibiting all possible interpretations of these words. (XML::Simple comes to mind here, which has an API so complex at this point (with its own strict mode!) that the name is almost comical.) This just screams to me like we need to have better standards than canceling out words English language that can be used to mean something. Instead of ruling out the words Easy, Tiny, Simple, Fast, and any other word, we need to have better standards to make sure these words are still meaningful to us. It'd be easier to have a new module up called Log::Fast and have it take 30 minutes to actually log something, thus ruining he idea of ::Fast, but it'd be more worthwhile changing its name to Log::FsckingSlow and not ruin ::Fast. And it would be even better to just do it right altogether and make Log::Fast justifiable. You utterly missed the point, though arguably I made it in a misleading way. I did *not* say that XML::Simple isn’t simple. The point is that “simple” in “XML::Simple” means “parses XML documents into plain Perl data structures” rather than “has a simple API” or “consists of simple code” or some other kind of simplicity. I am *not* saying that you should avoid certain words because they might become lies. *Any* word can be a lie. I am saying that “simple” has so many different meanings that it doesn’t actually say anything useful. If I see a module called Exception::Easy in a list of modules, I have *absolutely no idea* what it does. In contrast, if it was Exception::Class::Functions, I could immediately guess pretty well at what it does, even if I didn’t know exactly. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
Hello Aristotle, thanks for your feedback. On Sun, Jun 29, 2008, Aristotle Pagaltzis wrote: * Lutz Gehlen [EMAIL PROTECTED] [2008-06-28 13:55]: The module uses the package Exception::Class::EasyThrow but I don't know if this is really a good name. It seems fairly reasonable to me. Putting it inside the Exception::Class:: namespace seems better than not; but once you accept that, the problem is that any name you pick is inevitably going to be quite long. The last reply of sawyer x convinced me that the Easy extension is maybe not so bad. Exception::Class::Easy would also be a bit shorter than EasyThrow. Thanks, Lutz
Re: Name space: throwing exceptions easily
# from Lutz Gehlen # on Monday 30 June 2008 11:43: If the only call needed is mk_exception_functions(), that could just be import(). Well, the reason against that is the mk_exception_methods function I just mentionend. But I had not thought of using import, Yes, even in the case of creating methods, this could be done with options to import() rather than requiring the caller to inherit you as a base class. If you can possibly avoid requiring inheritance as an interface to these sorts of meta-class tools, it allows the user more flexibility in defining their class hierarchy and eliminates the risk of method name clashes between the meta and their own parent class. Extra points if you implement unimport(), which means the caller can say 'no Meta::Thing' so that the functions only exist at compile-time. This eliminates all risk of cryptic, tricky, and unexpected run-time errors from method-lookup name clashes. --Eric -- But as to modern architecture, let us drop it and let us take modernistic out and shoot it at sunrise. --F.L. Wright --- http://scratchcomputing.com ---
Re: Name space: throwing exceptions easily
Hi Lutz, * Lutz Gehlen [EMAIL PROTECTED] [2008-06-30 20:30]: The last reply of sawyer x convinced me that the Easy extension is maybe not so bad. personally I find ::Easy and ::Simple no more useful than ::Foo. It says absolutely nothing about what kind of ease or simplicity I can expect, and CPAN has plenty of examples of such modules exhibiting all possible interpretations of these words. (XML::Simple comes to mind here, which has an API so complex at this point (with its own strict mode!) that the name is almost comical.) * Lutz Gehlen [EMAIL PROTECTED] [2008-06-30 20:45]: My module installs functions because I see an exception as something that belongs to a package. However, I already thought about also offering an mk_exception_methods function for people who prefer to throw an exception with a method call. […] But I had not thought of using import, it's a nice idea. You’ve seen Sub::Exporter? Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
Hi sawyer x, thanks for your suggestion. On Sun, Jun 29, 2008, sawyer x wrote: How about Exception::Easy ? The idea to put it out of the Exception::Class name space is definitely worth considering because my module can in fact deal with any class that implements a throw method and I am planning to make it still more flexible in a future version. However, Exception::Easy sounds too much to me as if it would implement yet another exception framework which is not the case. I hope to find something more descriptive of what the module does. Thanks for your input, Lutz
Re: Name space: throwing exceptions easily
I've personally noticed that a lot of modules use an Easy subspace to show it's an interface or ability that's stripped down and made simple for you. I think this would be your emphasis. That you haven't written a new framework, but present an easy way to use the existing ones. For example: IO::Pty::Easy which uses IO::Pty. Maybe a different keyword you would be interested (which seems popular) is *::Simple. For example: CGI::Simple (which uses CGI.pm), SVK::Simple (which uses SVK.pm). This is just how it would seem to me if I were looking for a simple exception handler that makes using exceptions easier. On Sun, Jun 29, 2008 at 1:13 PM, Lutz Gehlen [EMAIL PROTECTED] wrote: Hi sawyer x, thanks for your suggestion. On Sun, Jun 29, 2008, sawyer x wrote: How about Exception::Easy ? The idea to put it out of the Exception::Class name space is definitely worth considering because my module can in fact deal with any class that implements a throw method and I am planning to make it still more flexible in a future version. However, Exception::Easy sounds too much to me as if it would implement yet another exception framework which is not the case. I hope to find something more descriptive of what the module does. Thanks for your input, Lutz
Re: Name space: throwing exceptions easily
* Lutz Gehlen [EMAIL PROTECTED] [2008-06-28 13:55]: The module uses the package Exception::Class::EasyThrow but I don't know if this is really a good name. It seems fairly reasonable to me. Putting it inside the Exception::Class:: namespace seems better than not; but once you accept that, the problem is that any name you pick is inevitably going to be quite long. The only suggestion that occurs to me is the File::Spec vs File::Spec::Functions precedent, which would suggest Exception::Class::Functions for your module. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Name space: throwing exceptions easily
# from Lutz Gehlen
# on Saturday 28 June 2008 04:51:
__PACKAGE__-mk_exception_functions
(messages = {foo = 'Error foo occurred.'},
exception_class = 'Exception::Class::Mine');
and later just call
foo() if($foo);
This requires you to inherit from the exception class, but it installs
functions instead of methods?
If the only call needed is mk_exception_functions(), that could just be
import().
--Eric
--
Issues of control, repair, improvement, cost, or just plain
understandability all come down strongly in favor of open source
solutions to complex problems of any sort.
--Robert G. Brown
---
http://scratchcomputing.com
---
Name space: throwing exceptions easily
Hello everybody,
I am developing a module to make throwing Exception::Class objects
easier. The goal is to make the code to throw an exception shorter
and to make it possible to keep all error messages at some central
place.
The module works quite similarly to Class::Accessor and provides a
function mk_exception_functions that puts the required functions
into a given namespace. For example you can define an exception
like
__PACKAGE__-mk_exception_functions
(messages = {foo = 'Error foo occurred.'},
exception_class = 'Exception::Class::Mine');
and later just call
foo() if($foo);
instead of
Exception::Class::Mine-throw(message = 'Error foo occurred.')
if($foo);
Currently the module uses the package Exception::Class::EasyThrow
but I don't know if this is really a good name. It is a bit vague
and rather refers to the intended use of the module instead of what
it does.
I would be happy about other suggestions.
Thanks a lot,
Lutz
