>
> Are you moving to parser generator, like lex/yacc, or hand coded?
>
I currently evaluate if there is something that can handle my ideas, but I
think I will create on of my own.
>
> The reason I want this is so that when I'm sending output downstream to
> another filter (like the syntax highligher example above, or something
> like GzipChan), it can move in smaller chunks and not consume huge tracts
> of VM.
>
Embperl 2.0 will be much better for chaining things. I will keep your ideas
in mind, when I make the final design.
>
> > > D. Some way of implementing inheritence on %mdat and perhaps %udat.
> > > The idea here being able to implement attribute inheritence that kicks
> > > in when a key doesn't exist in the hash. Whether this would be better
> > > done in Embperl.pm or EmbperlObject.pm, I haven't figured out.
> > >
> >
> > That's a good idea. The question is how how should this inherence work?
> > Where in which %mdat/%udat should Embperl look next when a key doesn't
> > exist?
>
> Cop out: just let the caller provide a "keyfault" function for each
> of the hashes that gets called on a FETCH or STORE with non existent
> keys. Maybe that isn't such a good mechanism: how would you iterate
> over the keys?
>
> Anyway, some uses for inheritence might be
>
> - inheriting attributes for a display object, like what format to put
> dates in or how to diplay a month (%mdat) for a calander display
> object.
>
There it would make sense to me to have the same inherence tree like
EmbperlObject has, kind of up-the-dir-tree
> - inheriting permissions from groups (%udat)
>
How do we create a group? A user for %udat, is just a session key. Maybe
there could be a function that defines: This user is of group X. This
function has to be called from the user page?
> - inheriting preferences from profiles (%udat, %mdat)
>
> The kind of up-the-dir-tree inheritence implemented by EmbperlObject
> is nice for displayable resources, but implementing a type tree or
> a permissions tree that is independant of the file structure layout
> would be handy.
>
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.
> 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?
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: [EMAIL PROTECTED] Voice: +49 6133 925151
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
