On Dec 7, 2011, at 10:33 AM, Dmitriy Sintsov wrote:
> * Trevor Parscal <tpars...@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.
_______________________________________________
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
