Hi Sebastian,
>
> The idea for not_after was that this list should contains objects which
> should not directly get a semicolon after them. For syntactical reasons:
> e.g. case foo:;
>
I see. In a sense, the reason I added "block" to not_after was indeed to
avoid a semicolon after it for syntactical reasons, that is when it is
immediately followed by another block (previousType == "block" and (current)
child.type == "block"). Maybe I stretched the meaning of "syntactical
reason"
a bit: here the reason doesn't apply to the "block" object itself but
instead to a sequence of two consecutive objects...
> I've no example for double semicolons. But better we protect it, then in
> the else case. Do the current code works OK for you (doesn't produce any
> errors)?
>
Yes it works, it simply adds a redundant semicolon between adjacent
blocks, e.g.:
{
<...code1...>
}
{
<...code2...>
}
becomes:
{<...code1...>};{<...code2...>}
but this is not a real problem, since the resulting code is correct and I
think it is very uncommon finding such two adjacent blocks in real code.
Thank for your clarifications.
Cheers,
Alessandro
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
