On Jan 21, Arthur Corliss wrote:
> Greetings:
>
> I previously submitted Object::BaseClass for consideration as part of CPAN.
> I've spent the better part of this day reading pods for the Class::* modules,
> and I believe that my module would probably be better classified here.
>
> I'm still requesting inclusion in CPAN based on the following reasons:
>
> --I haven't found a module on CPAN (correct me if I missed it)
> that tracks parent<->child relationships (in terms of the
> parent being a container for its children) and does an orderly
> termination of objects as a result automatically
Be careful about your terminology here. "Parent" and "child"
have well-established meanings in OO literature. They refer to the
"is-a" relationship (inheritance), not the "has-a" relationship
(containership). A base class has a well-established definition as
a virtual class from which one inherits.
This confusion may also be limiting your success in finding other
classes that provide similar functionality. For example, Class::Container,
Class::Composite::Container, Meta::Ds::Container, Class::UI::Container,
Class::Class, Class::Struct::FIELDS, POE, and probably several other
CPAN modules may hover around the functionality you're interested in.
> --While some modules provide auto-accessor capabilities, they
> don't do so in quite the same manner, nor do they combine
> that capability for psuedo properties like state flag registers
> --Most do not provide a psuedo event-handling mechanism, either
>
> A little background on methodology:
>
> This module is meant to be subclassed. A custom object would provide one
> mandatory method which is called by the constructor. This method defines the
> object's properties and flags, which consists of (optional) event handlers
> for each flag, and read, write, or unified property accessors. A generic
> accessor is provided and can work in any of the mentioned modes. All custom
> handlers and accessors would account for the rest of the derived class.
>
> Both flags and properties are exposed directly in the interface as virtual
> methods, with a standard interface. Flags and properties are handled
> differently internally, but internal methods do all conform to a standard
> method of invocation for each type.
>
> Events are triggered by manipulation of the state flag registers.
>
> So here's where you can tell me to go away, if need be. I believe that this
> peculiar mix of functionality would be somewhat tedious to reproduce from the
> existing modules, and hence, could be made available as a CPAN module.
>
> If you guys don't think I'm barking up the wrong tree, I would suggest that a
> better name would be Class::Hybrid or Class::Generic. I would be happy to
> hear any suggestions you have as well.
The functionality you're trying to provide is clearly useful; I think
that naming is really key to your module being *discovered and used* by
the open source community. Mention containership, or static definition,
or deterministic destruction, or declarative programming, or ownership
hierarchy in the class name.
- Kurt
