AJAX.NET and prototype.js

[Tony]

I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if this
is the same "prototype. js" that is not well-liked around here?

If so, do you know if Ajax.NET can be used without prototype.js?
--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

[Randy Webb]

Tony said the following on 6/28/2006 2:00 PM:

I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if this
is the same "prototype. js" that is not well-liked around here?
All it would take is to compare the file size and the first 10 lines or
so to see if they are the same.
If so, do you know if Ajax.NET can be used without prototype.js?

That would required testing it without prototype to see if it still
"works" or not.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices -

[Tony]

Randy Webb wrote:

Tony said the following on 6/28/2006 2:00 PM:

I just noticed that prototype.js is one of the files in the Ajax.NET
distribution - I'm pretty concerned about this. Does anyone know if
this is the same "prototype. js" that is not well-liked around here?

All it would take is to compare the file size and the first 10 lines or
so to see if they are the same.

If so, do you know if Ajax.NET can be used without prototype.js?

That would required testing it without prototype to see if it still
"works" or not.

Obviously, I was hoping to hear from someone who had already been
through this experience :)
--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

[Jeremy]

Tony wrote:

the same "prototype. js" that is not well-liked around here?

It's not well-liked? I think it can be really useful, as long as you
know what you're getting into when you use it and code accordingly.
IMHO, saying it's inherently bad is like saying the C++ STL is bad.
Sure, it's not part of the language per se, but if you want to make use
of the functionality it provides then what's the harm?

Just don't expect that any Prototype-independent libraries will still
work (although there are only a few problems that it causes - most
notably with for-in loops, which don't seem to be that widely used, and
in any case should never be used with any pre-assumptions about what
members they will discover).

Am I missing some big "gotcha" that's turned the community against this
library?

Jeremy

[Tony]

Jeremy wrote:

Tony wrote:

the same "prototype. js" that is not well-liked around here?
It's not well-liked?

Based on a number of posts I've read over the past month or so, yes.
I think it can be really useful, as long as you
know what you're getting into when you use it and code accordingly.
Perhaps, but that is a different discussion.
IMHO, saying it's inherently bad is like saying the C++ STL is bad.
I didn't say it was inherently bad. My question (that you didn't quote,
BTW) was if the Ajax.net one was the same one.
Sure, it's not part of the language per se, but if you want to make use
of the functionality it provides then what's the harm?
And if I DON'T want to make use of it?
Am I missing some big "gotcha" that's turned the community against this
library?

Take a look through this group's recent discussions on the matter, or
see http://www.javascripttoolbox.com/bes...ces/#prototype for a
quick summary.

So, are they the same?

--
"The most convoluted explanation that fits all of the made-up facts is
the most likely to be believed by conspiracy theorists. Fitting the
actual facts is optional."

[Matt Kruse]

Jeremy wrote:

Just don't expect that any Prototype-independent libraries will still
work (although there are only a few problems that it causes - most
notably with for-in loops, which don't seem to be that widely used,
and in any case should never be used with any pre-assumptions about
what members they will discover).
That is quite an assumption.

If I do:
var name = {'first':'bob'} ;

and then cycle through its properties, I expect to see 'first' and only
'first'. Otherwise, using an Object as a "Hash Table" isn't possible.
Am I missing some big "gotcha" that's turned the community against
this library?

http://www.javascripttoolbox.com/bes...ces/#prototype

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com

[Jeremy]

Matt Kruse wrote:

If I do:
var name = {'first':'bob'} ;

and then cycle through its properties, I expect to see 'first' and only
'first'. Otherwise, using an Object as a "Hash Table" isn't possible.

So why not use an Array as a "Hash Table"? Is that not what it's for?
Note: I'm not trying to be a jerk or come off as dense; I'm genuinely
interested. Does the ECMAScript specification require that an object
not have inherent properties, or that these properties not show up in a
for..in loop? The specification is pretty lax on that, and I would
argue that you shouldn't be relying on those assumptions in order for
your program to work.

Incidentally, it seems like this particular problem ought to be fixable
by setting the DontEnum attribute of the methods and properties that
prototype.js adds to Object. But I really have no idea if this is
implemented in user-agents; I'm sure someone would have implemented into
the library if it were feasible.

http://www.javascripttoolbox.com/bes...ces/#prototype

An interesting quote from your link:
"If you are writing code which only uses Prototype and nothing else,
then it can make your life simpler in often ingenious ways."

I'm not necessarily trying to argue that it's wise to use prototype.js -
I'm just arguing that the problems it causes are ALSO a symptom of
assumptions made by the people who diss it.

Jeremy

[trevorscottprice]

> Take a look through this group's recent discussions on the matter, or

see http://www.javascripttoolbox.com/bes...ces/#prototype for a
quick summary.

The fact that carelessly throwing in an otherwise useful script
framework might cause problems does not at all mean "the community is
against" it. Most people who use prototype improperly are probably
novices, and thus not active in "the community".

In my use, prototype has been very useful, and I also enjoy using the
effects libraries (e.g. rico) that are built on top of it.

[Laurent Bugnion]

Hi,

Jeremy wrote:

So why not use an Array as a "Hash Table"?

JavaScript allows to add properties dynamically to any object type. You
could even use an Image if you want. However, Array and other types have
already defined properties (Array.length, for example), which will
appear when you do a for...in. Additionally, in the case of a
"hashtable" , these properties are unused, and disturb more than they
help. This is why it's better to use Object for a "hashtable" (but then
again, if someone external added properties to the Object prototype,
then you got the same problem, QED)

HTH,
Laurent
--
Laurent Bugnion, GalaSoft
Software engineering: http://www.galasoft-LB.ch
Private/Malaysia: http://mypage.bluewin.ch/lbugnion
Support children in Calcutta: http://www.calcutta-espoir.ch

[Richard Cornford]

Jeremy wrote:

Matt Kruse wrote:

If I do:
var name = {'first':'bob'} ;

and then cycle through its properties, I expect to
see 'first' and only 'first'. Otherwise, using an
Object as a "Hash Table" isn't possible.
So why not use an Array as a "Hash Table"? Is that not
what it's for?

Absolutely not. the only thing that allows an Array to be used as a
"Hash Table" is the fact that arrays are instances of the native
ECMAScritp object, so it is their objectness that would be being
employed not their arrayness. Arrays are for referencing elements by
integer index, and automatically tracking the largest index assigned
with the length.
Note: I'm not trying to be a jerk or come off as dense;
I'm genuinely interested. Does the ECMAScript specification
require that an object not have inherent properties, or that
these properties not show up in a for..in loop?
All of the specification defined properties of Arrays and Objects are
marked with the - DontEnum - attribute and for-in is specified as not
enumerating properties marked - DontEnum -.
The specification is pretty lax on that, and I would
argue that you shouldn't be relying on those assumptions
in order for your program to work.
I don't think the specification is lax in this area (See the last
sentence of paragraph 11 in ECMA 262, 3rd Ed. Section 15). Implementers
are allowed to add properties as extensions, but it would be careless of
them not to mark such extension properties - DontEnum - themselves, and
I don't know of any implementation extensions to Array or Object that do
show up in for-in loops.
Incidentally, it seems like this particular problem ought
to be fixable by setting the DontEnum attribute of the
methods and properties that prototype.js adds to Object.
You don't design good javascript code by wishing javascript was some
other language. It is quite clear that that the attributes of properties
are not intended for runtime modification (otherwise the - Internal -
attribute would be listed separately as it would not make sense for that
one to be modifiable).

It was a poor design decision in Prototype.js to extend the prototypes
of Object and Array, and its authors cannot excuse themselves with a
desire not be creating the extra objects necessary to extend Array and
Object further down the prototype chain (or by augmentation) as the
library itself continually creates and discards an excessive number of
superfluous objects as it runs.
But I really have no idea if this is implemented in
user-agents; I'm sure someone would have implemented
into the library if it were feasible.
It is not.

<snip> ... prototype.js - I'm just arguing that the problems it
causes are ALSO a symptom of assumptions made by the people
who diss it.

Like assuming that the language specification is not explicit about the
enumerability of the properties it defines?

Richard.