On Dec 7, 2011, at 10:33 AM, Dmitriy Sintsov wrote:
- Trevor Parscal tparscal@wikimedia.org [Tue, 6 Dec 2011 17:21:43
-0800]:
The hype of "2.0" aside, is there a guideline for what should
constitute
a major version number change?
It looks like we are doing something like: Major.Minor.Release
1.18 = Major: 1, Minor: 18, (alpha|beta|etc.)
I'm just curious what people think would constitue a major version. We've certainly had major rewrites of systems in the past that didn't seem
to
justify a version bump. Is there anything wrong with having version 1.249? Is there a practical reason for bumping the version at some point
(like
when the minor version hits tripple digits)?
Also, a rewrite of MediaWiki should for sure be done in Node.js :)
- Trevor
Is Javascript really that good? Some people dislike prototypical inheritance, it seems that jQuery prefers to use wrappers instead (that's a kind of suboptimal architecture). Also, Google had some complains about Javascript flaws (for example primitive types don't allow high performance available in Java / C#), suggesting to replace it with something else.. Although having common clientside / serverside codebase is nice thing, for sure. And there's nothing more widespread than Javascript at client side. Also, it's object side is strong (something like Lisp with C-syntax), however it does not have generics, named parameters etc.. Dmitriy
I don't know how much you know about JavaScript but in my opinion it's often misunderstood. I think it's superior than most other programming languages because it's very expressive and it's simplicity is what allows great complexity. Bad parts are kept in for compatibility, but once you start treating those bad parts like they don't exist (by not using them, ever) one is left with a language that is still as powerful. (btw, that's the great thing for being a developer, we have the power to basically "remove" parts of the language without changing the standards or breaking other peoples code).
It's fairly easy to use it in a classical inheritance way, (i.e. use "classes" that extend from classes and use "constructors" for creating objects), which can't be said for languages that use classical inheritance, there is no way to do prototypal stuff there.
JavaScript's true power comes into play when using prototypal inheritance directly (creating objects that inherit directly from other objects).
jQuery uses prototypal inheritance as well, it's what makes jQuery what it is.
jQuery('#bodyContent').find( 'a' ).addClass( 'foobar' );
That chain is possible because the jQuery constructor (which is tucked away and calling jQuery( .. ) just does "return new jQuery.fn.init( .. );") which creates an object that inherits all members in jQuery.prototype and does so by reference (not by value)
So when a jQuery plugin is loaded onto the page at any time (that defines jQuery.prototype.myPlugin), all existing jQuery objects will have that method. And because all those methods return "this", you can call another method on the return value in a chain, and so on.
jQuery did choose not to extend the browsers' native objects' prototypes but that's purely a policy created because of how browsers work not because of how the language itself work, it's technically possible and other libraries such as MooTools do do that.
Indeed it's functions are primary citizens and object system is what makes it so strong. Since virtually any value other than null and undefined is an object, including numbers, strings and functions.