in reply to Re: xQuery functionality in Perl?
in thread xQuery functionality in Perl?

I guess I don't see the advantage of having something like this built into the language. It's both easy and reasonable to implement it in an extension (i.e. a "library" or "module").

(PS: qx is already in use.)

Replies are listed 'Best First'.
Re^3: xQuery functionality in Perl?
by rg0now (Chaplain) on May 20, 2005 at 17:01 UTC
    Interestingly, what the OP describes (basically, to promote XML expressions and constructs to first class objects) is not so foreign to language designers. I know at least to cases when it was done: one is Comega for C# and the other is XML::XSH. The latter one lets you mix in Perl and XML expressions, so it is really nice example of building XML into the language.
Re^3: xQuery functionality in Perl?
by DougWebb (Initiate) on May 19, 2005 at 18:22 UTC

    Sure, my example is easily done using XML::LibXML, but it'd take a lot more code. This is similar to the fact that regular expressions in other languages are generally implemented as add-in libraries, and have the same capabilites as perl's regexes, but are a lot more cumbersome to use.

    Also, if this were implemented as a native type, I have a gut feeling that it'd fit naturally into other expressions in a way that would be unnatural or impossible with the library approach.

    For example, I'd bet Storable would be able to persist an xmlnode scalar to disk, and read it back in, in a way that looks just like persisting any other datatype. This is something that you just can't do with XML::LibXML without going through a complete deparse/reparse cycle, and the maintainer of XML::LibXML is pretty adamant about keeping it that way.

    There would probably also be more natural fits with existing perl keywords, like grep/map/sort/foreach, which are cumbersome when you need to use a libraries methods to work with xml.

    That's my hope, at least.

    Doug.

    PS: yeah, I thought qx was already in use, but you get the idea

      I'd bet Storable would be able to persist an xmlnode scalar to disk, and read it back in, in a way that looks just like persisting any other datatype.
      Storable does a fine job with complex data structures, including objects.
      ...just can't do [it] with XML::LibXML without going through a complete deparse/reparse cycle...
      I don't believe that's avoidable.
      ...it'd take a lot more code...
      I still don't buy it. Witness:
      my $xml_fragment = XML::Struct->new( <<EOF ); # fictitious... <records> <record id="001">foo</record> <record id="002">bar</record> </records> EOF my @nodeset = $xml_fragment->xQuery( "//records[@id = '001']" ); die "ids should be unique!\n" if @nodeset > 1;
      Why is that so bad?

      In general, any suggestion that the core language should be changed to accomodate a specific domain or technology should be held at arm's length.