# Implement/Check scalar ties

# Ensure new is available & documented for V2

# Check tie behaviour with persistent files (e.g., picks up written values on
# first read).  'Component exists' (as opposed to element exists) should be
# mean 'tied'

# Arrays - clear should not delete storage; reset sohuld
# Arrays/General - tie should be invoked only upon assignment to the collection

# Add to list methods:
# Add x_clear to reset array without resetting storage (so storage exists, but no members)
# x_count(1) - count set values; (2) - count defined values; (3) - count true values
# x_grep x_map x_for
# x_areset to return a list of indices of set items
# ITERATOR
# ITERATOR over set values (leave the user to do ITERATOR over defined values,
# etc.)

# Add x_setref to hash, array as discussed in respective 'x' method
# documentation.

# Remaining array tests

# Integrate Class::MethodMaker::Util

# Add _exists, _delete(as for hash) to array

# test forward methods on tied attributes (they're set up in scalar.t,
# array.t, hash.t?, just not actually tested)

# Add introspection
# Split doc. for scalar across actual methods, a la array
# Tidy up doc writing to eliminiate unnecessary =pod =cut sequences

# differ clear & reset; define behaviour in terms of storage (therefore, tie)
# finish & document array
# finish array.t (check test notes at end)
# tie scalars
# split methods into files in their own directory
# split methodmaker further; turn V1 opts into own class hierarchy?
#                          ; remove bits that are needed only for class
#                            manufacture (OPTEXT, more?)

# document 'new'

# Check user-defined components still work as they used to

# Filehandle, Dirhandle, Code components?

# Automatic storage translation?  Retrieval translation?  Should this just be
# considered a likely implementation of tie?  Or implemented with tie?  Or
# would it be faster directly?  This could also be used to implement tied data
# _items_, as opposed to tied _components_.

# Copy method  (deep copy?  shallow copy?  probably an option for both)
# freeze/thaw integration  (is there really any value in doing this ---
#                           storable already does it)?
# Use of array-based classes?
# Use of closures for linked-lists, other data-structures (i.e., the instance
# is a subref that's closed over the data).
# Use of closures as above for iterators?
# Iterators over components
# Destructor that unties any components

# Finish Documentation
# Reassign names so error messages come from "right" class name & method
# Place doc. for data structures in middle of man page
# Add +*_clear syntax to add in non-default methods
# Add nonnull option
# Add triggered & monitored types
# Add ints, strings, timedates
# Add enums
#  Document default_ctor simple value trick with -type to work only with class
#  types.
# TODO from C::MM 1
# Add trees, linked lists, non-destructive hashes, fib heaps
# Integrate other CPAN data structures?
# Mechanism to allow users to define templates of methods they commonly use
# Test for error messages when new, catalalogue are given "standard" options
# Add forwarding from one method to another with a different name.  Add
#   mechanism for auto_naming, e.g., '*_name', where * is replaced by component
#   name, to allow methods to be forwarded to multiple components e.g.,
#   { -forward => {mode => '*_mode'} }, qw/ st1 st2 / to allow st1_mode &
#   st2_mode
# What to do with forwarding to a null value --- explicit check?
#   Require default value?  Just let it happen?
# Add writing out of source code to generated classes
# Add default_count mechanism to array
# Add parameter passed to default_ctor of array specifying slot ID
# Add purely generated arrays/hashes; unable to set, both with & without a
#  finite limit.  Are there CPAN modules for this?
# Add _lock & _unlock methods to lock values.  Limit each to certain classes?
# Add ties

# Add introspection capability for OODoc.  See email from Marcel Gruenauer
# <marcel@noug.at>