Question for SHLOMIF (and everyone else)
Hi all, I'm writing my own parser to handle the complete ISO SGML specification (using the excellent Marpa::R2 by JKEGL). At the moment, it's purely a recreational effort, but the long-term plan is to get it on CPAN. Part of the plan is to store the parser output in the same format as XML::LibXML (since if you squint at it right and wish very hard, XML can do everything SGML can do), and it struck me that I could probably even subclass that module to give free functionality to the parsed SGML through the many modules that are already written to handle XML::LibXML. I just wanted to make sure I'm not going to be stepping on any toes (or muddying any waters) by doing this, especially by using the SGML::LibXML namespace for the class name of the parse results. The parser itself would live in some other package name, maybe SGML::Marpa or something, unless SGML::LibXML::Parser seems like a cromulent choice -- I tend to think not, though, because it's not using the LibXML parser to actually do the parsing. Any hints, tips, comments, questions, or suggestions? -- P/PW/PWBENNETT
Re: Problem naming a module
Hi Philippe, there are two issues causing a problem with naming for this module: 1. very specific form of input required/expected (hash of weights) 2. tightly bound to a DSL as its API If you want to be descriptive then you simply cannot give a module like this a terribly generic name. To cover (2), you need ::Rules. To cover (1), you basically need to name all aspects: takes a hash, specifically one where the values are weights, and reduces it to a single value. So I ended up with Hash::Reduce::Weighted::Rules It’s a mouthful but seems necessary to accurately summarize the module. None of the names that omit any of these components felt satisfactory: whichever one you take out, the shorter name seems to describe a very different module. I did try to fit “Categorize” in there but it just isn’t specific enough to *replace* any component of the name, and if you just *add* it to the whole kit and caboodle, the name becomes ludicrous. So I left it out. So that’s the best I could do. Regards, -- Aristotle Pagaltzis // http://plasmasturm.org/
Re: Problem naming a module
On Mon, Nov 25, 2013 at 12:27:58PM +0100, Aristotle Pagaltzis wrote: there are two issues causing a problem with naming for this module: 1. very specific form of input required/expected (hash of weights) Actually, having seen the output of List::Categorize, it's not hard to make my module support a hash of arrayrefs (i.e. the output of List::Categorize), and just count the items in the arrayrefs. Enforcing consistency of the hash values is probably unnecessary. (Garbage in, garbage out) Still, directly or indirectly, a weighted hash indeed. 2. tightly bound to a DSL as its API Yes, the DSL was actually the start of the project. A colleague basically wanted to be able to process results of Nagios checks to monitor services instead of hosts. We quickly ended up talking about having a way to describe the result, using a DSL. The benefit of that DSL is that it can fit in a single line in a config file, or even be parsed for correctness in a web form, without giving users the full power of Perl. If you want to be descriptive then you simply cannot give a module like this a terribly generic name. To cover (2), you need ::Rules. To cover (1), you basically need to name all aspects: takes a hash, specifically one where the values are weights, and reduces it to a single value. So I ended up with Hash::Reduce::Weighted::Rules It’s a mouthful but seems necessary to accurately summarize the module. None of the names that omit any of these components felt satisfactory: whichever one you take out, the shorter name seems to describe a very different module. Many thanks for taking the time to work it out. I totally agree that Hash::Categorize is much too generic, for example, and following List::Categorize, should work with a coderef written in Perl, instead of a DSL. I did try to fit “Categorize” in there but it just isn’t specific enough to *replace* any component of the name, and if you just *add* it to the whole kit and caboodle, the name becomes ludicrous. So I left it out. So that’s the best I could do. Speaking of Categorize, can't we shorting Reduce...Rules to Categorize? Quoting Wikipedia on Categorization: According to the classical view, categories should be clearly defined, mutually exclusive and collectively exhaustive. This way, any entity of the given classification universe belongs unequivocally to one, and only one, of the proposed categories. reduces it to a single value sounds like an accurate description of categorizes. It's probably impossible to remove Hash::Weighted, as it's really what the input is, one way or another. Which would leave us with Hash::Weighted::Categorize. The other option is to give up on being descriptive, and come up with a brand name. In which case, Fleur is just as fine as anything else. :-) -- Philippe Bruhat (BooK) No matter how you dress a cow, it still gives milk. (Moral from Groo The Wanderer #46 (Epic))
Re: Problem naming a module
On Mon, November 25, 2013 5:27 am, Aristotle Pagaltzis wrote: Hi Philippe, there are two issues causing a problem with naming for this module: 1. very specific form of input required/expected (hash of weights) 2. tightly bound to a DSL as its API If you want to be descriptive then you simply cannot give a module like this a terribly generic name. To cover (2), you need ::Rules. To cover (1), you basically need to name all aspects: takes a hash, specifically one where the values are weights, and reduces it to a single value. So I ended up with Hash::Reduce::Weighted::Rules Itâs a mouthful but seems necessary to accurately summarize the module. None of the names that omit any of these components felt satisfactory: whichever one you take out, the shorter name seems to describe a very different module. I can't disagree much, but I find that returning to my suggestion of GroupBy works well with: Hash::GroupBy::Weighted since GroupBy implies Rules. For what it's worth. -john
Re: Problem naming a module
On 11/25/13 8:04 AM, Philippe Bruhat (BooK) wrote: On Mon, Nov 25, 2013 at 12:27:58PM +0100, Aristotle Pagaltzis wrote: [snip] The other option is to give up on being descriptive, and come up with a brand name. In which case, Fleur is just as fine as anything else. :-) No, it's not. Fleur implies a superclass of Rose, which this is not. :-)
