Gerald Richter wrote:
>
> yes, of course, but I still have no good idea how define the inherence tree.
> Ok, we could provide the keyfault callback, then it would be up to the user
> to define his own inherence schema. I keep it in mind.
Thanks. I think leaving up to the CMS author to define varied and wondrous
forms of inheritence is good, though the more obvious forms (up-the-dir-tree
and some type of type based inheritence) should be built in or easily doable.
>
> > Perhaps a get()/set() API would be better than tie()in the hashes,
> > though.
> >
>
> 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?
set()/get() doesn't imply key iteration. And people could inherit
from Embperl to provide them instead of callbacks.
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.
Just my 0.02c, of course.
- Barrie
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
