> From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
>
First of all, I very much like summary and the idea of using a constant
to represent NULL. That will make any issues with the storage used in the
implementaion go away (i.e., Hashtable vs HashMap).
I would suggest the the constant be defined as part of the Context
interface. It is a developer level concept and should be visible to all. So
I would propose:
public interface Context {
public static final Object NULL = new Object();
....
}
This works fine, I use it in my failed attempt to change #macros into
#subroutines. Remember.
More inline...
>
> Christoph :
>
> > "Geir Magnusson Jr." wrote:
> > [SNIP]
> > > 4) We want to handle the app side putting null keys and
> values into the
> > > context w/o throwing our hands up and saying 'let the
> implementation
> decide'
> > > or having to sprinkle try{} blocks everywhere.
>
> > OK (but note that null keys isn't really required but can be added
> > analogosuly to null values). I see this is aiming at the solution
> > proposed below.
>
> No, I don't mean we keep null keys, just that we handle them
> and drop them.
> As long as we return null from a get(null), all is well...
>
I really see no reason for null keys. At least at the VLT level.
> > >
[snip]
>
> > Note that Jose also proposed a $?foo syntax.
>
> I think it was earlier than that, and soundle thumped down by
> jon, I think.
>
I saw a proposal for ?$foo but mine was $?foo ;-)
In any case, notice that what I was proposing was for "$?foo" to evaluate
to a boolean value. That means that it will render "true" or "false" and
that it will be evaluated in #if and #set as booleans.
I do not know if the other proposals are in the same spirit.
[snip]
>
> > Please note that sometimes returing null is desireable:
> > #set( $dummy = $hastable.put("KEY", "woobie") )
> > Do I have to place a bang into $!hastable to avoid a message?
>
> No, you don't have to put a bang. That is only for rendering,
> and you are
> not rendering when you are on the RHS of a #set().
>
Is the reason with this issue with the $hastable.put() the fact that put()
returns a value? What about if put() returned void? Just wondering.
Maybe we need something like #ignore( <expr> ) which causes the evaluation
of expression but renders nothing. Well maybe ingore is not the best name
;-)
>
> > [snip]
> > - for #5, we preserve the idea that chained contexts are
> immutable (if we
> > decide we want that), and by putting NULL into the 0th or
> local context,
> we
> > would functionally 'remove' the chained value so it won't
> be accessable.
> > because we mask it : the local get() returns the NULL object.
>
> > -0 for immutable chained contexts. It should be the
> implementation/application
> > to decide that (more below).
>
> Yuck. Agreed for app-defined context implementations (that's
> one of the
> points of all this : application freedom to hang yourself...)
> But the Vel
> provided impls should not allow chained context alteration, I
> believe. I
> think altering the chained context is a special thing,
> application specific,
> will be rarely used, and better be done by a clueful person.
>
> > >
> > > This would be a useful feature with chaining : a
> framework could fill a
> > > context with a complete toolset, and then a permission
> layer/manager
> could
> > > chain that context and 'mask off' the tools that aren't
> allowed for a
> given
> > > user/session/whatever.
>
> > exactly!
>
> But you do it by chaining the base context, and then adding
> nulls -> NULL to
> mask off in the 0th level context. You can then use that, or
> pass it to
> someone else to chain with. You don't actually alter the
> context that was
> passed to you. You do have that option, of course. If I hand you a
> context, you can just diddle with it directly. But if you
> chain it, or I
> chain it before giving it to you, I can protect it from you.
>
> > >
> > > What's missing?
> > >
>
> > Missing the notion of a mutable chained contexts and a #local...#end
> directive.
>
> Look, you have the freedom to implement mutable chained
> contexts, or set up
> your framework so each layer can alter directly, chain and alter with
> masking, or chain to protect and pass it down... and since
> AbstractContext
> has a 'getChainedContext()' method to extract (I threw that
> in there...
> anyone hate it? I sort of do now... :) the inner context,
> you can at app
> level screw with the inner context.
>
> Can you give an example of functionality you wont have if the
> inner context
> is shielded from put()s by the 0th level context?
>
Here I can give you a very concreate example that comes from our discussion
on how VMs work. As you remember one of the points I was trying to make was
that arguments to VMs were re-evaluated on every ocurrance in the macro.
And the suggestion was made to use #set() if only one evaluation was
required. Well additionally you need to do something like chaining to make
sure the variable used for the #set is not already used outside of the
macro.
So far so good, chained Contexts can work.
However, if the VM is suppose to change the state of the incomming context,
then we cannot use chaining because it will be lost when leaving the VM. Ex:
#macro(m1 $p1)
#local($a)
$set( $a = $p1 )
$set( $appVar = $a + $a )
#end
#end
Now if we use inmutable chained contexts for the implementation of #local
then things will not work as expected because there is no way to put $appVar
in the outer context.
Now, given the new arquitecture, the implementor of #local can define its
own implementation of Context which is semi-permeable. Only things declared
as local live in the local scope, the rest go thru. This is not difficult at
all to do.
Now, the challenge is, can we do the same without using an additional
context? I think it is possible, but...
Jose Alberto
