* Dave O'Neill <[EMAIL PROTECTED]> [2007-07-18T14:10:54] > > I'm not sure what we really want, and I am eager to hear ideas. I would > > like to keep things fairly simple. Here's a simple idea whose merits and > > flaws I have not deeply considered, yet (it just popped in there): > > [ ... ] > > My random thoughts: > > I'm not too keen on introducing Yet Another Way of doing objects. Do you > think name collisions are going to be a huge problem? Is trying to > enforce namespaces for attributes really going to buy us anything, when > someone could just implement an Email::Whatever that extends Email::Base > and mucks about in the top level of the hash for its object data anyway?
Name collisions are not a problem until they are, at which point they are a massive problem, because some schmendrick calls his autoreply plugin's method "reply" which someone else is using for "is_reply?". That said, the real solution may be to look for the redefinition warnings and pay attention to wtf you are doing. I am definitely with you: I am not excited about introducing another way to do objects if we can happily avoid it. > What about inside-out objects? It might be handy for dealing with > hundreds of lightweight objects (headers, message metadata for all > messages in an mbox, etc). I have no a priori objection to them. Is there a system for building them that is fairly lightweight and portable? We should try to establish some rough guidelines about what the goals of PEP-produced code *are*. I think Email::Simple needs to keep having roughly zero pre-reqs and keep running on 5.005. I am probably fine with Email::Base requiring 5.6 and having a few very useful prereqs. I'm not sure how many "a few" or how useful "very useful" are. I mean, do we want to use Moose? It always comes up, half in jest. I don't know what its performance or maintenance impact are. I don't think it adds *that* many prerequisites, but I haven't looked up the whole tree. > And... another random thought on objects. Do we want to enforce a > naming convention for accessors? YES. So much. > get_foo() and set_foo() vs a foo() method that changes behaviour based on > args? I like the get/set version mostly because it's easier to grep for in > the code, and harder for someone to accidentally screw up. I don't mind get/set. I also like mutators. I think I'd prefer get/set. More importantly, I want them to be freaking standardized. I am so tired of: $frob->set_foo( $thing->foo); $object->foo_set( $thing->foo ); -- rjbs
