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.
