String vs Symbol use cases

Ideally, both:

> myDocument / 'entity' @ 'name'
>
> or
>
> myDocument / #entity @ #name.

should work. You are here defining a small api to formulate xpath queries, which is great. However, I am not sure that your api will cover all features offered by xpath. The syntax "myDocument xPath: 'entity/@name’”  may also be supported.

Alexandre



--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Ah okay!

Alexandre


> On Sep 17, 2015, at 2:55 PM, Peter Uhnák <[hidden email]> wrote:
>
> You are here defining a small api to formulate xpath queries, which is great.
>
> Nono, this is XPath library by Hernan (available from Catalog Browser), I'm just using it.

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Peter, the XPath lib was rewritten not long ago to provide full XPath 1.0 support + extensions, so feel free to mail me with questions or bugs. The old lib didn't implement the whole spec and would crash or infinite loop on valid input, so I felt a rewrite was needed.

> myDocument xPath: #'entity/@name'

I think treating Symbols as Strings is a bad idea. On GS, Symbols aren't Strings, and #foo = 'foo' is false, so in the XPath lib itself (which now supports GS), I NEVER use Symbols as Strings. But on Squeak/Pharo, this won't hurt you. if you don't need porting, do what you like.

> myDocument / 'entity' @ 'name'

This is the "DSL" syntax.  There are binary messages for each XPath axis: // for "descendant", //~ for "descendant-or-self", ~ for "self" and more in the "enumerating - axis" category. The XPath compiler actually generates sends of these but with block arguments that don't need parsing (string arguments are treated as NameTests and can have wildcard or type tests like '*', '*:foo', or 'text()'). Because the string args are parsed every time, using xPath: can be faster if you save the compiled XPath (like in an inst/class var: "savedXPath := 'some/path' asXPath") and reuse it (with "aNode xPath: savedXPath"). There's also a global compiled XPath cache that's checked before compiling an expression, so xPath: can still be faster even if you don't bother saving.

Remember the xPath: usage gives access to full XPath syntax (not just axis and nametests), including predicates, functions, and variables. XPath is really a different language so mapping it all to a ST DSL is tricky. For example, XPath 1.0 is weakly typed so "1" = 1 = "1.0" but clearly this is false in ST. Be aware of the differences when you go from one to the other.

> Remember the xPath: usage gives access to full XPath syntax (not just axis and nametests), including predicates, functions, and variables. XPath is really a different language so mapping it all to a ST DSL is tricky. For example, XPath 1.0 is weakly typed so "1" = 1 = "1.0" but clearly this is false in ST. Be aware of the differences when you go from one to the other.

By this I mean XPath has many JavaScript style implicit conversions. for example, if an XPath predicate evaluates to a node set, it's converted to a boolean: true if non-empty, false otherwise. Collections in ST obviously aren't converted automatically to true or false when used with ifTrue:ifFalse:.

Hernan maintained the old lib. The PharoExtras/XPath lib you get from the catalog or config browsers was rewritten and questions/bugs should be sent to me. Note it is incompatible with Pastell, so you can't have both in the same image.