[aethr]

Anything I can do with a string, I could also do with an array. However, it would take extra work to make an array behave like a string, in the form of helper functions, etc.

If I really wanted to prove a point, I could make a string behave like an array. But that would take even more work because an array is a very flexible tool used for a variety of low level purposes.

Therefor, according to your argument, a string is a more primitive data type because it takes more work to make a string act like an array than it does to make an array act like a string. This goes in direct contradiction to the actual definition of a programming primitive.

Back to the original poster's quote, "JSX offers a solid class system much like the Java programming language, freeing the developers from working with the too-primitive prototype-based inheritance system provided by JavaScript."

He is quite clearly addressing a specific case here, which is programmers who want to use Java-like classes when developing in Javascript. A lot of extra work is required if you want to make a Javascript prototype behave like a Java class, with inheritance, etc. So in this context, it is obvious that Javascript prototypes are "too primitive" for the task at hand.

Similar to the way that strings are, in fact, arrays with lots of extra functions for frequently repeated, string-related tasks, JSX classes are JS prototypes with a lot of the oft-repeated boilerplate code done for you. I'm not sure how to make it more clear how the chain of "primitiveness" flows in this case.

[ZenPsycho]

You're kind of stretching the metaphor a bit far here. In the javascript language interpreters, prototypes are implemented with classes. In JSX classes are implemented with prototypes. In C, strings are implemented as arrays. In shell scripting, arrays are implemented with strings. All we get out of this is that whether a programming construct is low level or high level is relative to how it was implemented, and is not an intrinsic quality of the construct itself. This doesn't make any sense to me.

[aethr]

Something being "a primitive" is entirely based on implementation details. Not implementation details of how the language interpreters/compilers are constructed, but how you as a programmer implement things in the language in question.

A associative array might be considered a language primitive in PHP, but not in C. It is contextually dependent on the language being discussed.

Without speaking about a specific language, you cannot define something as a primitive or not in the strictly programming sense. Once you start talking about comparing two types of constructs in an abstract sense, the word primitive can only be interpreted using the English common usage, and then you are talking about an entirely different concept.

[ZenPsycho]

Re-reading this... It's clear what is "a primitive" in javascript. but what does "Too-Primitive" mean? The sense of the word "primitive" as in language primitive is a set, not a quantity. Something is either a primitive or it is not. there's no such thing as "too primitive"

[aethr]

You're right, when talking about a primitive type in the programming sense, something either is primitive or it isn't.

I took this phrase to mean that the prototype construct is "one step down on the composite type hierarchy" from what is needed to emulate as a Java-style class.

Rather, its a good building block but the necessary boilerplate code makes it "too basic" for that purpose. Therefor this developer has created a type further up the composite type hierarchy (or further away from the primitives) to accomplish his goal.

I don't think he's trying to suggest any deficiency in the expressiveness or capability of the prototype construct (he's obviously quite familiar with it to create this language). This is simply a tool for people who aren't familiar with (or don't make use of) that aspect of Javascript to be productive by utilising a more brief, or possibly more familiar (ie Java) syntax.