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

On Sunday 24 August 2003 12:42, Mark Anderson 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.
>
> 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".

Fair enough. I'll move this function into a new file.

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

Agreed.

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

That actually sounds like a great idea. Once we have a public p4 repository 
for burst (I'm yelling at my provider (yet again), who won't be able to get 
our new server up before tomorrow), a little Python or Perl foo will be in 
order methinks.

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

Well, they won't be as fast as compiled methods, but that's OK for most 
things.

> 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 share those concerns. Would a big disclaimer of some sort in the docs be 
enough? They are getting kind of long, so it might be harder to have some 
disclaimer stand out. Can you think of other ways to make it clear to 
"outsiders" that these properties and methods are non-standard? Perhaps some 
sort of prefix or suffix to the names?

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

Which, in the end, is mostly what I care about. I'm looking to make sure that 
our code is readable, while still making our lives easier to hack on the 
toolkit. If the ballance shifts too far in the direction of easy-to-hack at 
the expense of readability and comprehensibility, I'll get concerned.

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

That's true. Shame about it too.

> 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'm 
starting to think that our library needs a good fast collision free hashing 
function for strings too (cryptographic properties optional).

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

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