Re: Re: [Netwindows-cvs-notify] netWindows/winScripts fix_ecma.js, 1.1, 1.2

>>Mark Anderson wrote:
>>
>>>This is actually against the spirit of fix_ecma.js, whose only
>>>purpose is to compensate for inadequate ECMAScript 262-3 implementations,
>>>most particularly IE5.0 PC.
> 
> 
> But that's the thing about ECMA-script. If we feel it's inadequate, we can fix 
> it. And I think that most of the string functions in JS are completely lame. 
> I like the approach of fixing the tools we have if it's simple and 
> straightforward.

There's a difference between fixing an inadequate implementation, and
extending a standard.
The purpose of fix_ecma.js is to make the native JS objects behave
according to ECMA 262-3.
If we are going to *extend* the standard, then I think we should put
it in another file, say "extend_ecma.js".

There could potentially be a lot of functions there, as *all* the
native objects have infelicities in their interfaces (String, Array,
Function, Regexp, Date, Object).
Functional programming could be cleaner by extending Function.
Date formatting could be cleaner by extending Date.
The extreme ugliness necessary to do Object typeof testing for
null and undefined could be obviated.
And so on.

I think if we do add this, then we should define all such functions
in terms of other fully qualified functions in the library (much the same
as we would do for global convenience functions).

So it would be:

extend_ecma.js

   String.prototype.trim = function() {return burst.Text.trim(this);}

burst/Text.js

   burst.Text.trim = function(s) {return s ? s.replace(/^\s+/,'').replace(/\s+$/,'') : s}

In fact, I could imagine that the file extend_ecma.js could be automatically generated,
with a little help from source conventions in other files.


> I'm OK with it going somewhere else (like utility_core.js), but I think I 
> dissagree about extending native objects. If the performance sucks, then we 
> shouldn't do it, 

I can't imagine performance would be an issue, certainly not if we are
extending native JS objects (vs. native DOM objects).

My main objection is that those who look at the code later will:
(a) be confused about what is actually available in the standard, and
     will attempt to copy the code elsewhere and be confused by its failure;
(b) be unaware of hidden dependencies within the library.

I agree that the technique is convenient from a code writing perspective.

At least JS doesn't support operator overloading, so there is a limit
to the extremes this could be taken.

> I am planning to use this approach for something like Python's printf-style 
> text replacement. The following Python code illustrates the interpolation:
> 
> 	foo = "foo bar baz"
> 	bar = 1234
> 	result = "here's a string: %s, and here's a number: %d" % (foo, bar)
> 
> which yields:
> 
> 	"here's a string: foo bar baz, and here's a number: 1234"
> 
> I think that JS needs a similar operator, and I plan on doing it to the String 
> prototype directly (that, and a join() method).

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.

-mda



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