Changes between Version 4 and Version 5 of RFC59-Draft

Timestamp:

Aug 6, 2010, 9:38:07 AM (14 years ago)

Author:

sdlime

Comment:

--

RFC59-Draft

@@ -69 +69 @@
 Some of these definitions hint at other features that will be detailed later. When we convert an expression string into a series of tokens we also store away the value associated with that token (if necessary). In many cases the token value is a litteral (string or number), in other cases its a reference to a feature attribute. In the latter case we use the attributeBindingObj already in use by MapServer to encapsulate the information necessary to quickly access the correct data (typically an item index value).
 
+We always have had to make expression data available to the parser (and lexer) via temporary global variables. That would continue to be the case here, although different data are shared in this context. One thing to note is that once an expression is tokenized we no longer have to rely on the flex-generated lexer so, in theory, it should be easier to implement a thread-safe parser should we choose to do so.
+
 '''Extending the Yacc grammar to support spatial operators'''
 
@@ -81 +83 @@
 }}}
 
-We can use these tokens in the grammar to implement all of the MapServer supported (via GEOS) logical operators.
+We can use these tokens in the grammar to implement all of the MapServer supported (via GEOS) logical operators. Note that in the above example fromText() appears as a function operating on a string. This is handled as a special case when tokenizing the string since we only want to do this once. So we create a shape literal based on the enclosed WKT string at this time.
+
+'''Extending the grammar to support spatial functions'''
+
+By supporting the use of more complex objects we can support functions on those objects. We could write:
+
+{{{
+  EXPRESSION (area([shape]) < 100000)
+}}}
+
+or rely on even more of the GEOS operators. (Note: only the area function is present in the sandbox.) To do this we need to somehow store a shapeObj's scope so that working copies can be free'd as appropriate. I would propose adding a ''int scope'' to the shapeObj structure definition. Shapes created in the course of expression evaluation would be tagged as having limited scope while literals or bindings would be left alone and presumably destroyed later. This saves having to make copies of shapes which can be expensive.
+
+'''Context Sensitive Parsing '''
+
+We could have done this all along but this would be an opportune time to implement context sensitive parser use. Presently we expect the parser to produce a true or false result, but certainly aren't limited to that. For example, at the moment you can write:
+
+{{{
+  CLASS
+    ...
+    TEXT ([area] acres)
+  END
+}}}
+
+It looks as if the TEXT value is an expression (and it is stored as such) but it's not evaluated as one. It would be very useful to treat this as a true expression. This would open up a world of formatting options for drivers that don't support it otherwise (e.g. shapefiles). Ticket [http://trac.osgeo.org/mapserver/ticket/2950:2950]
+
+== Expression Use Elsewhere ==
 
 == Backwards Compatibility Issues ==