NAME

Class::MakeMethods::Docs::ToDo - Ideas, problems, and suggestions

SYNOPSIS

There are lots of things that could be done to improve this module.

DISTRIBUTION ISSUES

Issues about the distribution and supporting files, rather than the code:

Documentation

Make sure that the documentation is broken up into appropriately-sized chunks, and that people will know which section to look at.
As user questions arrive, add the answers as documentation points or examples.
Assemble annotated examples and tutorials, and either link to or distribute them.
Finish overhauling Template documentation.
Include Global and InsideOut uses in the EXAMPLES section
Template Internals: Finish documenting disk-based meta-method code-caching.

Tests

Use Devel::Coverage to measure test coverage, and fill in missing cases.
Finish tests for Standard and Composite modules.

GENERAL ISSUES

For scalar methods (and others) it would be nice to have a simple bounds-checking interface to approve or reject (with an exception) new values that were passed in.
As pointed out by Terrence Brannon, the right interface to adopt is probably that of Attribute::Types:
```
  use Class::MakeMethods::Standard::Hash (
    'scalar' => [ 'count' => { TYPE => 'INTEGER' } ],
    'scalar' => [ 'name' => { TYPE => qr/^[A-Z]\w*$/ } ],
    'scalar' => [ 'account' => { TYPE => &checksum_account_number } ]
  );
```
Improve use of _diagnostic hooks for debugging. Add various "(Q)" debug diagnostics.
Finish building Inheritable array and object accessors.
Finish building Composite::* packages.
Resolve DESTROY-time issues with Standard::Inheritable, Composite::Inheritable, and Template::InsideOut.
Add slice and splice functionality to Standard::*:hash and Composite::*:hash.

TEMPLATE CLASSES

Template::Generic

Allow untyped object accesors if class attribute is not set. (Suggested in Jan-01 NY Perl Seminar discussion.)
Standardize naming templates for array, hash, other method types.
Deprecate verb_x methods? Or at last make them consistently available both ways.

Make list methods consistent with hash_of_lists methods, in action, and in name (x_verb). Also for others (e.g., set_ clear_ boolean)
Should default object template provide auto-create behavior on ->get()?
Generalize the "Generic:scalar -init_and_get" interface to support memoizing values for other accessor types.
Consider adding hash each and array iterator methods, using a closure to provide iteration.
Add support for tied arrays & scalars, a la tiedhash
Add string_multiple_index.
Extend index methods to support weak indexes with WeakRef. Perhaps just have it accept a hash ref to use as the index, and then allow people to pass in tied hashes?
Maybe make private or protected method croak if they were called by a method_init method which was called by an outside package.
Not entirely clear what the right semantics or security precautions are here...

Template::Generic Subclasses

Finish building code_or_scalar meta-method.
Finish building Class::MakeMethods::ClassInherit subclass.
Need to work out how to capture changes for non-scalar values. For example, if a subclass inherits an array accessor and then pops it, do they get copy-on-write?
Add enumerated string/number type.
Provide helper methods with map of associated values (ex $o->port = 80 ... $o->port_readable eq 'HTTP' ). Cf. code for earlier unpublished 'lookup' method type.
For StructBuiltin:
Add -fatal flag to die if core func returns false / undef Add call method to recall method with alternative arguments. Add -nocall flag to not call core func on new.
Replace ClassName:static_hash_classname with Class:indexed_string.

Template Internals

Figure out which modules, if any, should actually be using AutoLoader. Probably just Template::Generic?
Give users a way to do meta-method code-caching in Perl library hierarchy, rather than in /tmp/auto or other user-specified directory..
Provide mechanism for pre-generating these at install time.

Perhaps load these via do, rather than open/read/eval?

Perhaps pre-generate expanded libs with all of the -imports resolved?
Support generating code files and loading them as needed.
This would be similar to Class::Classgen, except that we'd do the generation at run-time the first time it was required, rather than in a separate pass.

For example, given the following declaration:
```
  package Foo::Bar;
  Class::MakeMethods::Template::Hash->import(-codecache=>'auto', scalar=>'foo');
```
We should be able to write out the following file:
```
  cat 'auto/Foo/Bar/methods-line-2.pl'
  # NOTE: Generated for Foo::Bar by the Class::MakeMethods module.
  # Changes made here will be lost when Foo::Bar is modified.
  package Foo::Bar;
  sub foo {
    my $self = shift;
    if ( scalar @_ ) {
      $self->{'foo'} = shift();
    }
    $self->{'foo'}
  }
```
Then on subsequent uses, we can just re-load the generated code:
```
  require "auto/Foo/Bar/methods-line-2.pl";
```
To do this, we need to:
- Provide an option to select this if desired; maybe ... import('-cache' => 'auto/', ...)?
- Figure out which directory we can/should write into.
- Re-evaluate the textual code templates, without generating the closures. Substitute in any _STATIC_ATTR_ values. Make other _ATTR_ values point to some public lookup table or package scalar.
- Notice if the source file (or Class::MakeMethods modules) has been updated more recently than the generated file.

CPAN RT