X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=TODO;h=2d80f9de5209c738d788be0649be70c323417cca;hb=e347ce3fe9e40dc060e73e07f282729f4191c878;hp=38440fc6b838bc3e1dd6e2e195ef39cf196a3711;hpb=7b31baf476f970830c62cafa82d8f2efcd4ac1b6;p=gitmo%2FClass-MOP.git diff --git a/TODO b/TODO index 38440fc..2d80f9d 100644 --- a/TODO +++ b/TODO @@ -1,74 +1,52 @@ --------------------------------------------------------------------- TODO ---------------------------------------------------------------------- - -- have the init_arg be automagically filled in if it is not present - -(DONE) - -This will simplify some code, and really is not very expensive anyway - -- clean up bootstrapping to include the accessors, etc for attributes - -(PARTIALLY DONE) - could use some tests - -Having all this meta-info is useful actually, so why not add it, and -let the methods get overwritten if they need to be, its a small price -to pay for what we get from it. - -- clean up all ->initialize($_[0]) handling - -(PARTIALLY DONE) - needs tests - -We should always be sure that $_[0] is a package name, and not -a blessed intstance. - -- make &compute_all_applicable_attributes not return a HASH - -(DONE) - -All the info in the HASH is discoverable through the meta-object. - -- General Purpose &clone_instance method - -(PARTIALLY DONE) - need to implement the deep cloning & tests +--------------------------------------------------------------------- + +[23:47] Theory stevan: What do you think of the use of key names as substitutes for class names that Class::Meta uses? +[23:48] stevan Theory: key names? +[23:48] Theory stevan: All Class::Meta classes have key names. +[23:48] Theory They're short aliases, basically +[23:48] stevan oh +[23:48] Theory So Foo::Bar::App::Person might be "person". +[23:48] Theory This is useful for a few things: +[23:48] Theory 1. Database mapping (table/view names) +[23:48] Theory 2. easy type specification +[23:49] Theory 3. Use in other contexts (e.g., URLs) +[23:49] Theory So in effect, class key names in Class::Meta are also types. +[23:49] Theory So I can say +[23:49] Theory has user => ( type => 'person'); +[23:49] Theory instead of +[23:49] Theory has user => (type => "Foo::Bar::App::Person"); +[23:50] Theory Anyway, the key name stuff is essential for the ORM stuff I do. +[23:50] Theory Which is why I'm asking you for your thoughts on it. +[23:50] stevan where is the mapping stored? +[23:50] stevan and how and when is it computed? +[23:51] Theory It's just another attribute of the Meta::Class object, +[23:51] Theory If it's not specified, it just grabs the last part of the package name. +[23:51] Theory and lowercases it. +[23:51] stevan but is there any global map anywhere? +[23:51] Theory But it has to be unique. +[23:52] Theory yes, Class::Meta stores a hash that maps key names to Meta::Class objects. +[23:52] Theory So you can say +[23:52] stevan k +[23:52] stevan yeah Class::MOP has a similar thing +[23:52] Theory my $meta = Class::Meta->for_key('person') +[23:52] Theory Which is great for mapping URLs and database tables. +[23:52] stevan Class::MOP::get_metaclass_by_name('Foo::Bar::App::Person') +[23:52] Theory yes, but it's only package names, right? +[23:52] stevan I could add Class::MOP::get_metaclass_by_key('person') +[23:52] stevan yeah it is +[23:53] Theory not a substitute key word. +[23:53] Theory Yes, that's what I'm thinking, exactly., +[23:53] stevan yeah that would be fairly easy actually +[23:54] stevan I have been pondering (for a very long time actually) a Smalltalk like class browser +[23:54] stevan it would be very useful in that context +[23:54] Theory Glad to hear it. :-) +[23:54] * stevan jots another note onto the TODO list -It can be a method of the metaclass, like construct_instance is, -actually it should be called clone_instance, and it should -be thought of as a low-level cloning function, so it should not -do any blessing or anything of the sort. That is left for the -class to implement, as is the construct_instance. - -- General Purpose &new_object and &clone_object method - -(PARTIALLY DONE) - needs tests - -I seem to be writing a new method each time, but since we dont -have a Object class to always inherit from, this is needed. -However, there is nothing to say that I cannot do something like: - - Foo->meta->new_object(%params) - -and ... - - $foo->meta->clone_object($foo, %params) - -Give it some more thought, but I think it is the best way to -approach this. - -- Role/Trait/Scalar-style mixin mechanism - -This is fairly simple with the MOP, but the trick comes with -any SUPER:: calls. This will be a very tricky problem I think. - -* see Class::Trait::Base, and maybe use anon-classes for this. -* review the Scalar model for mix-ins -* I like the Class does Role, Role isa Class from Perl 6 idea. - -- metaclass.pm - -Should handle metaclass incompatibility issue, and do it through -class mixin composition. +--------------------------------------------------------------------- +EXAMPLES TO WRITE +--------------------------------------------------------------------- - Prototype-style example @@ -85,10 +63,8 @@ I am not sure how we should handle non-method arguments, mostly because those would be static prototype variables, which would translate to class package variables. -- Make a Class::MOP::Package -Class::MOP::Class would be a subclass of this, but I am not sure -this is worth the time. +