Karen, I was very angry when I wrote my reply, and despite my best efforts, some of that anger is reflected in the words and tone. I apologize for that. I did not intend that it be taken as a personal attack, and if that is the case, I am truly sorry. I have great respect for the work you have done for Perl, for the larger number of modules that you maintain.
I believe very strongly in the notion of an inclusive Perl community, with CPAN a core component, open to all for experimentation and publishing of code. That code might be odd, esoteric, useful only to a handful of others, or perhaps none, but sometimes that is the only tangible means by which a user can participate and contribute to Perl. There is an element of pride in having a module appear on CPAN, and perhaps to see it propagate as a standard package on various Linux distributions. Uploading a module to CPAN is often the first step into larger participation in the Perl community. CPAN is a venue for exchanging ideas, not just code. There are many modules which overlap in function, but each one provides insight into how one problem may have many solutions, or how what seems to be the same problem is actually several different ones. To me CPAN is a library, not just a toolbox. Again, my apologies for the lack of diplomacy. Diab On Fri, Sep 22, 2017 at 12:23 AM, Diab Jerius <djer...@cfa.harvard.edu> wrote: > > On Thu, Sep 21, 2017 at 5:11 PM, Karen Etheridge <p...@froods.org> wrote: > > > > Given that there is so much prior art in this space already -- is it > useful to release one more variant to the CPAN, vs. simply keeping it in > your darkpan? Is anyone likely to discover your module and choose it over > any other? > > What are you trying to accomplish here? You have just told me that my > effort is essentially not worthy of consideration on CPAN, that it is > redundant and derivative. That I should keep it to myself because it will > be lost and ignored, perhaps because it is not as brilliant as some other > piece of code, and so will not stand out. > > This is dismissive and patronizing. And so not Perl. > > If you have a technical reason for your comment, then back it up with > analysis. Present your evidence. You have made vague statements, with > enough ignorance to indicate that you have not actually examined my module > and compared it to the prior art. I know the prior art. I've examined it > closely, read the code, understood its advantages and disadvantages, looked > at its dependencies, used it in actual production code. Have you performed > any level of analysis before making your statement? > > What is the point of trying to discourage contributions to the community? > If your intent is to improve the quality of code on CPAN, I request that > you reconsider your approach. It is not helpful. It will drive people > away from the community, not improve CPAN. > > Have I misunderstood your statement? I sincerely hope so. > > > > > Please at least give a summary of the alternatives and how they differ, > in the documentation. > > That is a helpful suggestion. I have already done so. > > > > > PS. There's also Class::Struct, which is in core, and Class::Tiny, which > is the one I'd recommend for lightweight Moo*ish class declarations. > > > Thank you for those suggestions. Unfortunately neither is applicable > here, which is why they were not listed. They are classes which happen to > use hashes as storage. In my application, it is the hash which is of > primary importance, with the object reflecting the structure of the hash, > not the other way around. I refer you to the documentation for my module, > which I linked to, which describes the behavior of the object. Note that > since the module has been renamed, the github URL has changed: > https://github.com/djerius/Hash-Wrap > > The module closest to my needs is Hash::Objectify. It however uses > Class::XSAccessor, which inserts an XS dependency, which is not appropriate > in my application. Additionally, the result of retrieving a non-existent > element depends upon the history of that element (whether it existed and > then was deleted). This is documented behavior, and does not meet my > requirements. > > > On Thu, Sep 21, 2017 at 12:23 PM, Diab Jerius <djer...@cfa.harvard.edu> > wrote: > > > > > > > > On Thu, Sep 21, 2017 at 1:58 PM, Diab Jerius <djer...@cfa.harvard.edu> > wrote: > > > > > > > > > > > > On Thu, Sep 21, 2017 at 12:59 PM, Diab Jerius <djer...@cfa.harvard.edu> > wrote: > > > > > > > > > > > > > > > > > > > > On Thu, Sep 21, 2017 at 11:30 AM, Michael Greb <mich...@thegrebs.com> > wrote: > > > >> > > > >> On 09/20, Diab Jerius wrote: > > > >> > I've written a module[1] to scratch an itch, namely easily > wrapping hashes > > > >> > returned from subroutines as objects[2]. > > > >> > > > > >> > I've named it Return::Object, based on my particular use case, > but I'm > > > >> > finding it useful for more general wrapping of hashes, hence my > quest for a > > > >> > more general name for it. > > > >> > > > >> There seems to be a fair number of not directly connected modules > under the > > > >> Data::Hash namespace. I think placing your module alongside these > makes sense > > > >> so something like Data::Hash::AsObject, Data::Hash::Object, or the > like may > > > >> be fitting. > > > >> > > > >> Mike Greb > > > >> mikegrb > > > > > > > > > > > > > > > > Here's my current list of "almost but not quite" modules: > > > > > > > > Object::Result > > > > Hash::AsObject > > > > Data::AsObject > > > > Class::Hash > > > > Hash::Inflator > > > > Hash::AutoHash > > > > Hash::Objectify > > > > > > > > I'll look at the Data::Hash namespace and see what's there for > comparison. > > > > > > > > > > According to CPAN, the Data::Hash namespace only has four modules > (!?). That's a surprise. > > > > > > Data::Hash::DotNotation > > > Data::Hash::Transform > > > Data::Hash::Totals > > > Data::Hash::Flatten > > > > > > > > > > After visiting more of CPAN's dusty corners, and considering that most > similar modules are in the Hash:: namespace, I'm leaning towards > Hash::Wrap. My colleagues seem to think that has something to do with hash > (in the culinary sense) and wonton wrappers. Middle of the afternoon here. > Maybe they're hungry. > > >
