Gary L Peskin <[EMAIL PROTECTED]> wrote:
> Scott, what do you think about making this an abstract class instead of
> an interface?
Makes perfect sense.
> This does make sense but I didn't want to make the changes now. Just
> trying to get Norm's stuff working before doing a refactoring and
> cleanup.
Yep. Let's get 2.2.0 out first. We would like to release this Friday
morning, so we should wrap up any remaining changes real quick.
-scott
Gary L Peskin
<garyp@firste To: [EMAIL PROTECTED]
ch.com> cc: (bcc: Scott Boag/CAM/Lotus)
Subject: Re: Hack alert
07/11/01
02:57 AM
Please
respond to
xalan-dev
[EMAIL PROTECTED] wrote:
>
> Gary L Peskin <[EMAIL PROTECTED]> wrote:
> > What do you think about creating a _qn field
> > in VariableStack that would be a QName array.
>
> I would rather not. The variable stack itself is very clean now and I
> would rather keep it that way. I don't think a penalty should be imposed
> for the (forgive me) edge case of variable access by extensions.
Fair enough. That is why I brought the issue up.
>
> Can't Norm's problem be fixed by sensing when you are at the stylesheet
> level, and then switching to the global variable list in StylesheetRoot?
Yes, absolutely. I'm doing that next. The current setup does make it
harder when debugging for me (ie a human) to see what variable is what
on the stack. But I agree with your balance of not adding runtime just
for that and extension usage.
>
> Though the hack in Variable#execute and VariableStack#getVariableOrParam
> are ugly, and not what we want in the long run, at least for now they are
> well contained. They actually wouldn't be so much hacks if they were not
> in the XPath module.
>
> Here's what I think we should do instead: change the current
VariableStack
> into an interface for the use of XPath. When an XPathContext is created,
> the caller (Xalan XSLT in this case) passes in a
> org.apache.xalan.transformer.VariableStackImpl, where the current code is
> moved to. Then, getVariableOrParam is no longer such a hack, and we can
> add getVariableOrParamIndex for calling where the current hack is in
> Variable#execute.
Scott, what do you think about making this an abstract class instead of
an interface? It seems like an awful lot of the functionality would
have to be repeated in each implementation and it's unlikely that the
implementation classes would want to subclass another class and just
implement the interface.
>
> [aside: Well, getting the stylesheet element from the prefix resolver is
> still a hack. But this is general problem and not directly related to
the
> variable hack. :-) In other words, we shouldn't have to 'hack' in order
> to get the current stylesheet context from within an expression. We
should
> probably just have a method like Object getContainingContext() or some
such
> in XPathContext. This isn't that much different from getNamespaceContext
> ()... but it would look nicer in the code. ]
>
> I've had a pretty long day, so this may not make any sense when subject
to
> scrutiny. Does this hold water?
This does make sense but I didn't want to make the changes now. Just
trying to get Norm's stuff working before doing a refactoring and
cleanup.
Hang in there,
Gary
