Re: JS sprintf (was Re: extending core objects (was Re: [Netwindows-cvs-notify] ...))

>>extending String i suppose is one external API approach, but if it was
>>me I wouldn't implement it that way internally, as there I'd want
>>to support a "compiled" formatter object for greater performance.
> 
> 
> That had occured to me, but having witnessed the mess that is the JS regexp 
> objects, I don't think that the implied speed advantage really makes up for 
> the the syntactic lameness. We could also take a similar approach to current 
> JS interpreters regarding regexps and compile a formatter the first time we 
> see it, to be reused later if the same format string is called for.

I did something like this in my JS XPath implementation.
Changing the symbols to how it would be in burst:

    burst.xml.XPath("//foobar").iterate(rootnode, myfunc);

In the implementation, the function XPath may be called either as
a constructor or a normal function, though external callers should only
call it as a normal function.
Internally, it uses MOP functionality to memoize any prior call with
the same arguments; if there wasn't one it calls itself as a constructor.

["MOP" and "memoize" being concepts from other lineages I won't belabor here.]

You are right though that the compiled object need not be exposed;
string formatting could just be:

String.prototype.sprintf = function(fmt /*,...*/) {
}


> I'm 
> starting to think that our library needs a good fast collision free hashing 
> function for strings too (cryptographic properties optional).

I don't see how the this could be better than just using a native hash?

Certainly, JS suffers from not having a Object.hashCode() function, but
for String i don't see the need.

-mda



_______________________________________________
The netWindows developers list: [email protected]
http://netwindows.org/mailman/listinfo/devel_netwindows.org