On Tue, 21 Jan 2003, _brian_d_foy wrote:
> should this be in Class::* ?
You should have an updated e-mail in your box by now, I caught that snafu.
> how does this relate to the various modules in Class::, like
>
> Class::Classless
> Class::Object
> Class::Generate
> Class::Base
> Class::Fields
> Class::Accessor
> Class::Structured
Class::Classless: As I read the pod, doesn't provide more than a
psuedo-constructor (clone) that can have arbitrary data and methods attached.
Mine turns all described properties and flags into virtual methods, and allows
you to specify write-only, read-only, read-write accessors as part of the
property description. Furthermore, it has a rudimentary event system by which
flag modifications/accesses can trigger code execution.
Class::Object: This module doesn't appear to provide any functionality
different from Class::Classless, so see my remarks above.
Class::Generate: This is the closest to what I'm trying to accomplish.
I'm not doing dynamic (sub)class generation, and so, we're syntactically very
different. You can simulate an event-driven system with the 'pre' and 'post'
member specifications. I tried to make it cleaner by having events tied
directly to a user-defined state flag register, to encourage less code
entanglement (i.e., making operations more atomic, without having to call
specific methods, etc.). In addition, I've added facilities for tracking
parent<->child relationships (parent, as in container) for orderly destruction
of objects.
Class::Base: Again, not that different from Class::Classless or
Class::Object.
Class::Fields: A class extension, not a framework in itself. Still doesn't
provide much in the way of auto-accessors beyond what the above classes do.
Class::Accessor: Again, not that different from Class::Generate, but much
more limited in scope.
Class::Structured: Focused on class data structure, doesn't address extended
functionality described above.
> that sounds like Class::Accessor
See above.
> doesn't Perl already do this?
No, it doesn't. One problem I've had is with Curses programming, where I want
to make sure I've called delwin on all applicable derived/subwindows before
the parent window goes out of scope and auto-destroys itself in the object's
DESTROY handler. It gets more complicated when you want a referential trail
to follow that can be tracked both ways, from parent to child and child to
parent (think grand* both ways as well).
--Arthur Corliss
Bolverk's Lair -- http://arthur.corlissfamily.org/
Digital Mages -- http://www.digitalmages.com/
"Live Free or Die, the Only Way to Live" -- NH State Motto
