> >
> > The tied hash interface is shorter to write. You could always say
> >
> > $obj = tied (%udat) ;
> > $obj -> FETCH ('foo') ;
> >
> > then you have an get API, but what do you gain by that?
>
> The thought behinbd set/get API is that if you have a hash interface
> with the keyfault callback: how do you implement key iteration?
>
That would be hard of course, but you don't have a good idea how to make key
iteration, you can simply replace it by a warn "Not possible" and write it
in the docs!
> set()/get() doesn't imply key iteration. And people could inherit
> from Embperl to provide them instead of callbacks.
>
You can inherit from HTML::Embperl::Session and overwrite the FETCH and
STORE and so on. Currently there is no way to tell Embperl to use your new
class, but this could be changed.
> I'm not really concerned with the API form, just the generic
> functionality. I think Embperl is ideally positioned to capture
> a large core of the Perl based CMS arena, just by providing easy
> hooks for CMS authors to implement whatever inheritence and
> contextualality they desire.
>
I agree
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
