Article:		Non-Extractive Parsing for XML
Subject:		Many misunderstandings...
Date:		2004-05-22 13:42:49
From:		mweiher
Response to: Many misunderstandings...
You are not abstracting. You can hide an optimized implementation behind an interface that looks just like a regular string. In fact, this is exactly what MPWXmlKit does. To the client, it just provides NSString-compatible objects. Inside they are highly optimized and just point inisde the original data, but if something happens that can't be handled that way, it can resort to returning a more "normal" NSString. Polymorphism is a wonderful thing ;-) Marcel

Previous Message

Up

Next Message

• Many misunderstandings...
  2004-05-23 03:14:53 Brian Ewins [Reply]
  
  Unfortunately in this case, its not me thats not abstracting - its Sun. Yeah, sure you can do all kinds of funky things behind an interface, but String is a final class in java (ie you can't implement your own or subclass it, it just is what it is; hey it wasn't my idea!).

  
  ne_parseInt(String s1, int offset, int length) still isn't the signature to replace "Java's parseInt", if you want to avoid extraction. ne_parseInt(CharSequence s1, int offset, int length), possibly.
  
  

  • Many misunderstandings...
    2004-05-23 10:57:14 mweiher [Reply]
    
    So Java is broken...tell me something I don't know ;-)

    
    MPWXmlKit isn't implemented in Java, and the examples posted in the article aren't Java either...so how does Java enter into the equation?

    
    Marcel
    
    
    

    • Many misunderstandings...
      2004-05-23 11:41:15 Brian Ewins [Reply]
      
      It enters because that's what Jimmy was writing about - a java replacement for a java API. Quoting the article:

      
      "Yet most string-to-data conversion macros or functions, e.g. atoi, atof and Java's parseInt assume tokens in the "extractive" sense. To support the new "non-extractive" tokenization, one can create a mirror set of functions, e.g. ne_atoi, ne_atof and ne_parseInt (ne stands for non-extractive). "

      
      thats why I put quotes around "Java's parseInt" in the previous reply - I'd spotted your stuff was in Objective-C, I know you can do better :)

      
      In java even the supposedly high-performance 'standard' APIs (like SAX) use 'String' everywhere, and so can't be zero-copy like Jimmy's proposal; we have to resort to other hacks - eg I wrote a SAX parser once that used a ternary tree-based StringPool for element/attribute names, it massively reduced the number of strings being created - most parsers use java's String.intern() to pool strings instead, which creates masses of garbage to collect.

      
      Anyway I think I've written enough replies to this article... back to work...
      
      

      • Many misunderstandings...
        2004-05-23 13:37:45 mweiher [Reply]
        
        "It enters because that's what Jimmy was writing about - a java replacement for a java API. Quoting the article:"

        
        Huh?? He talks about XML/string parsing in general, not about Java in particular. Certainly the references to atoi(), lex, Macros and C are a pretty strong hint that it's not just Java we're talking about here...

        
        But not really important, I think we understand each other :-))

        
        Cheers,

        
        Marcel
        
        
        

        • Many misunderstandings...
          2004-06-22 12:57:15 jimmy_z [Reply]
          
          Marcel,

          
          We (XimpleWare) just released our XML processing software and it is at vtd-xml.sf.net. I would like to personally invite you to take a look. Your input and suggestions are very welcome.

          
          Cheers
          Jimmy