On Thu, 2002-01-03 at 19:35, Chuck Esterbrook wrote:
> On Thursday 03 January 2002 12:13 pm, Ian Bicking wrote:
> > The only annoying part is that the translation x.setY(z) to x.y = z
> > is hard to do in an editor. It can't be done just with regexes,
> > though, as it has to understand nested expressions.
>
> Why would it have to understand nested expressions? Aren't setFoo()
> methods always invoked as statements?
>
> foo.setBar(blahblah)
>
> Something like:
>
> $\t+[A-Za-z0-9_]+\.set[A-Z][A-Za-z0-9_]*\(\.+\)^
Well, it could be something like .setBar(x+(y*10))... though that might
not matter, since they will always be the only statement on the line.
But more like:
\.set[A-Z][A-Za-z0-9_]*\((.*)\)\s*^
You don't have to match the first part, which may be any expression
(e.g., self.request().setFoo(y)).
Of course, this won't work if you have done line continuation. I do
that a lot, since I tend to just nest expressions a lot. Really, you
have to do parenthesis-counting to deal with that. I.e., you have to
parse, not do a regex.
You could mark lines that include things like .setResponse( without the
proper trailing ) -- I'm drawing a blank on just which methods are going
to be replaced, since all I can think of is the multi-argument ones, so
I'm not sure how long the expressions are likely to be.
> I always get my regexes slightly wrong the first time, but the gist is:
>
> beginning of line
> one or more tabs
> identifier
> ".set"
> cap letter
> more alphanumerics
> "("
> 1 or more characters
> ")"
> end of line
>
> I think regexes could handle that. If they couldn't, we could certainly
> deal with the situation with our own code.
>
> Then axe the "set", decap the identifier, replace "(" with " = " and
> kill the rightmost ")".
>
> foo.setBar(baz)
> foo.bar = baz
>
> Or am I missing something?
>
> Actually, if you did that blindly you would screw up the occasional
> setFooBar() that takes multiple arguments, assuming these exist in
> Webware.
setHeader, setValue, etc.
I think we'd just want to match the specific ones we're replacing. You
could potentially replace (.*) with ([^,]+), which would avoid setHeader
and such -- but if you are setting something to a list or tuple, it will
give a false-negative.
> BTW Another thought is that Python comes with a module to translate
> source to AST nodes that can then be examined. If I remember right.
Yeah, but we don't want to do that, do we?
> But in general I agree with Tavis' comment that this could be done line
> by line.
>
> Also, I'm in favor and an "all the way" approach. e.g., a script that
> would translate 99% of code and mark problem spots with a tag that
> could be grepped for (assuming we didn't achieve 100%).
I mostly would worry that it could be fragile and wouldn't provide a
stable transition -- after all, the translator is meant to make Webware
a stable platform for development. For it to be stable, the transition
has to work really well.
With the less elegant technique of supporting the old interfaces through
alternate classes, you can make a system that works really well (since
it is only translating module and class names, and provides an interface
we already understand), and is very robust. With all the possible ways
the syntax can be represented, it's very hard to translate it -- what
about PSP, or even code written in Cheetah? There's going to be
dead-tree stuff out there that will enshrine a certain Webware
interface. Even if the new interface is a clear improvement, it will
still be easier for people if they can try older examples and such.
If it's just to provide convenience for moving old servlets to new code,
then a source-code-translator would be better, and it might be useful in
conjunction with providing old interfaces as well. But I don't think
convenience is the motivation for this backward compatibility, no?
Ian
_______________________________________________
Webware-discuss mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/webware-discuss
