|Problems? Is your data what you think it is?|
Thanks for the details. FWIW, I don't see the same thing in similar circumstances (I'm also on Mac OS, and Linux), but there were a couple of bugs in Build.PL I picked up from the RT queue, so I've fixed those and uploaded 2.08. I'd not used CPANPLUS before, being a roll-your-own kinda guy, but I tried it and it worked out of the box for me (with C::MM 2.07), so that's kinda weird. Do you have any non-default settings with yours?
I've resolved all the issues on the RT queue, I hope.
As to the generic thrust, I'll make the following points:
-) As far as forcing one to use hashes "I wonder how many folks want accessor generation only to find out they must use a blessed hash with canned modules?", I will observe that I did consider trying to be object-impl. agnostic, but chose against, for that would make the module even more complex, and the slanging on PerlMonks would have come all the faster. As it is, hash-based objects are the majority by an order-of-magnitude, and non-hash-based are used most commonly in specialist situations (e.g., performance-intensive ops) where you'll be avoiding generic solutions anyway.
-) The rest of the thread seems to me the general case of "I want the moon, and I'd like it on a stick". I'm referring to thread as a whole here, not specifically your posts. Of course we'd like modules to be simple to use, and (although it's often less said), we'd like 'em to solve complex issues. If they were simple issues, it wouldn't be worth the time surfing CPAN for them. So we end up with a trade-off: simplicity of use vs. complexity of problem solved. And wherever there's a trade-off, there's a team of people ready to criticize it. It is worthy of note that there's always a thread like this one, including the position (e.g., demerphq), of "accessor generators are wrong", and I regularly get requests for more feature additions. There's no pleasing everyone.
-) I see no problem of you writing you own module if C::MM and others don't suit your needs, either because they are too complex, or you want to use arrays/scalars/filehandles/whatever to implement your objs. Code reuse is about not re-writing code that does do what you need, not code that doesn't. If you were to write a module that assumes hash-based classes, with argument type-checking & optional tied storage, then I would wonder if re-using C::MM wouldn't make more sense, but it's your time & code.
-) C::MM does have many flaws, it is more complex than I would like, the documentation isn't as good as I would like, and I don't get to spend much time on it now that I have a daughter to look after. I'm happy to talk about those (subject to time). On the other hand, it's used in many places, I get positive feedback from many users, so I'm happy to have contributed what I can.
In summary, if you go to the farm and find a horse, by all means help me to make it run faster, but please don't complain to me that it doesn't give milk. You want a cow for that.
I appreciate that you weren't aiming to offend me, and I'm not offended; my comments are aimed at the thread as a whole. I do get a little tired of the complaints (at all free software) that it "doesn't do what I want". If as the complainants generated half as much code as commentary, there'd be a great deal less complaining to do. And that's definately not aimed at you Ovid - you clearly do produce the goods, so you've earned your right to a whinge.