* Krinkle krinklemail@gmail.com [Wed, 21 Mar 2012 18:51:45 +0100]:
Few points:
- The easiest way to understand it is to consider "sparse arrays" to
not
exist in javascript. It doesn't throw an exception if you try it, but it's not supposed
to
be posisble, so don't.
In Chrome, executing the following code: var a = []; a[0] = 'a'; a[2] = 'c'; worked, however debugger inspector shows 'undefined' elements between real elements of array. And the length is counted for 0..last element, including the undefs. However, for..in worked for such arrays fine, but may be inefficient - I do not think it has hashes or linked lists to skip the undefs, it probably just skips them one by one. That worked in IE8/IE9/FF/Chrome so I must not be first coder who used that.
I switches to {} and $.each() two days ago, so that's already the past.
- Sparse objects don't exist in any language afaik. What you created
is
just a regular plain object.
I was mentioning JS objects with numeric keys - I didn't know they are silently converted to numbers. Now I removed parseInt() from my code.
- As I said before I think there is no point in using $.each() in this case. It is nice if you need a context but as you already found out,
more often than not it's actually a burden to have to deal with it if you just want a loop inside an existing context. I would've kept the for-in loop you originally had which was just fine, only change the array into an object.
Maybe I'll switch to for ...in back then however I scared by "basic" prototypes so maybe I'll check .hasOwnProperty() then, too. Still haven't decided that.
I'd have to look further into the actual code to know what you mean here, but there isn't really such thing as "refactorign a JS class into a ResourceLoader module". For one, javascript doesn't have classes, but that's just word choise. Secondly, ResourceLoader "just" loads
Actually, creating JS function and assigning the prototypes to it and then instantiating it via new operator and then adding properties to it's context, including some from it's own prototypes works like classes. Prototypes are really similar to virtual methods tables available in another OO languages, but another languages manipulate them indirectly, in higher and better level than JS. Frankly, I am not much a fan of JS, however I have no another widespread choice for client-programming web.
You don't have to refactor anything. There are a few things that it enforces (such as execution of the javascript file in a local
context),
but other than that you don't have to change anything "for
ResourceLoader".
There are a lot of conventions and best practices often associated
with
"porting to ResourceLoader" but that's more along the lines of "now
that
we're working on this, lets get rid of crappy code and make it nice", not anything ResourceLoader actually requires.
I'm curious what kind of problems you are referring to here? The kind
of
problems you didn't have when you loaded jQuery in MediaWiki 1.15
The problems are simple - when I load another module with mw.loader.using, then call it's module from mw.loader.using callback, there is no return to original module. So I am enforced to build inflexible chain of calling main module directly from loaded module main context. I got used to it, although that was a little disappointment.
Now I have another pain: mw.msg() caches messages quite aggressively, even though I put the following lines in LocalSettings.php: $wgResourceLoaderDebug = true; $wgEnableParserCache = false; $wgCachePages = false;
I got the same old version of message, even after multiple Ctrl+R in Chrome, action=purge and even httpd restats. How can I make mw.msg() being updated every time I change i18n file of my extension? Maybe the evil provider caches some requests though :-( I probably should check with Wireshark. It's tiresome that fighting with environment takes too much of the time. Dmitriy