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

On Friday 22 August 2003 19:50, you wrote:
> 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.

> I can accept that. I put it there after talking about it with Alex. It's
> somthing that we've added internally that snuck into the tabbed_pane
> implemention we did. When Alex tried it out of cvs head, it complained.
> I just threw it into fix_ecma.js as a quick fix and b/c that _seemed_
> like a natural kind of place to put it. I'm happy putting it somewhere
> else.
>
> > So this should be put elsewhere.
> > And even then, I'm personally not a fan of extending the native objects
> > with non-standard methods.

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, but 

> > Instead, this might be done as
> > __util__.trim = function(s) {return s.replace(/^\s+/,
> > "").replace(/\s+$/, "");}
>
> This I disagree with this.
>
> The power of this is that you can do stuff like:
>
> var foo1 = (document.getElementById("foo")).value.trim();
> vs.
> var foo2 = __util__.trim((document.getElementById("foo")).value.trim());
>
> or more often:
>
> var foo3 = nwAppId.domNode.value.trim();
> vs.
> var foo3 = __util__.trim(nwAppId.domNode.value);
>
> I know that this is a fishy business to get into. From what I
> understand, this is what bit the dynaAPI guys in the rear end.

They were trying to extend DOM nodes to do everything but the kitchen sink. 
They've since retreated and IIRC they are moving to something similar to our 
logical-concrete mapping model. Their extension of core objects I don't think 
was that problematic, but I could be wrong.

> This is the only extension that we've added though out of all the js
> stuff we've been writing. It's a real time saver imo.

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).
	

> If you and Alex really don't like extending String to do this, I'll
> modify the tabbed_paned widget and remove the reference and replace it
> with code that uses __util__.trim() or put the regex code inline.

I'm fine with the current syntax. Although I might prefer that it be also 
aliased to String.prototype.strip as well.

Counter arguments? (as always, I'm willing to be convinced)

-- 
Alex Russell
[email protected]
[email protected]

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