>
> May be I didn't complete my thoughts in words, but that the
> whole point of
> my idea: make the interface as flexible as possible, now the
> implementation is up to us, nothing prevents us from using OO and
> subclasses. It's just that you don't have hardcoded
> subclasses, you write
> the subclassing on the fly.
>
> On the other hand, why do you think that would be slower? On
> the opposite,
> the non-subclassed approach will be faster as there is no search for
> methods in @ISA, all the methods are on the surface. We can go even
> further and use attributes to resolve the methods lookup at
> compile time.
yeah - I didn't mean to imply that it would be slower, only that I wanted to
make sure it wasn't :)
>
> If you know that most people will use stock Registry, why
> wasting cycles
> on constant resolving of subclassing.
>
> Another benefit I'm trying to reap is to move to constants,
> and make them
> set-able from the user space. Especially for debugging.
>
> The mechanism I suggest is simple:
>
> tell me which components do you want and I'll cook the
> package for you and
> compile it for you. Now you have a package like it was a real
> file on the
> disk, but you don't have to create any files ahead.
you know, I missed that the thing was cooked in your startup.pl - I
initially thought that the cooker was the Registry script itself, so I saw
hashref->subclasses->package as adding an additional wrapper. the design is
much better now that I've had my coffee ;)
>
> And as I've mentioned in this doc, if you want the old
> behavior just write
> wrappers which request the same features, previously were in effect.
>
> > > * global variables persistance: I suggest to have the
> cooker option to
> > > flash only globals at the end of each request.
> >
> > beware of those flashing globals ;)
>
> flushing, blushing :)
:)
--Geoff
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
