W3C home > Mailing lists > Public > public-qt-comments@w3.org > February 2004

ORA-XQ-151-E: pushState() with no argument is confusing and unnecessary

From: Stephen Buxton <Stephen.Buxton@oracle.com>
Date: 17 Feb 04 09:10:58
Message-Id: <200402171710.i1HHAwG25533@rgmgw5.us.oracle.com>
To: public-qt-comments@w3.org
Cc:

SECTION A.2.2: lexical rules

The action pushState is used inconsistently in the transitions,
sometimes with an argument and sometimes without.  The only
guidance to the reader is the sentence "In some cases, a 
transition will 'push' the current state or a specific state
onto an abstract stack...".  The reader is left to surmise
that pushState() means "push the current state" whereas
pushState with an argument means "push the argument state".
But if we look at the table for OPERATOR state, first row, 
we see the pair of actions:

  DEFAULT
  pushState(DEFAULT)

This seems to mean: first, change the current state to DEFAULT,
and then push the state DEFAULT on the stack.  In that case,
couldn't you just write the second action as pushState()?
If we look at the next to the last line in the same table, 
we see

  EXT_KEY
  pushState()

which seemingly means, change the current state to EXT_KEY, and
then push that state.  This leaves this reader confused, why 
in one case you chose to push the state explicitly, and in the
other case you did not?  I toyed with the possibility that the 
latter example is to be interpreted "change the current state to
EXT_KEY, but push the former state on the stack."  But if that
is your intention, wouldn't it be better to write it

  pushState()
  EXT_KEY

? (Actually, there is considerable evidence in other rules
that this is indeed your meaning; I am filing a separate comment
asking you to please list the actions in the order of execution
instead of this confusing reverse order of execution.)

The best solution in my opinion is simply to get rid of the
argumentless pushState -- always write out explicitly what
state you want to push.  That also eliminates the issue of order
of execution.

- Steve B.
Received on Tuesday, 17 February 2004 12:11:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:18 UTC