On 03/16/2012 11:36 AM, Sumana Harihareswara wrote: Sorry for the spam, but they've extended the deadline to the 30th: http://opensourcebridge.org/blog/2012/03/cfp-deadline-extended-until-march-… -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation

On 18.03.2012 18:26, Dmitriy Sintsov wrote: replaced 'new MarkerController(...)' calls to 'new mw.jqgmap.MarkerController(...)' calls left from incomplete refactoring of early working (non-broken) revision, however refactored separate view / edit modules code still does not work, with the same js code being stopped without additional Chrome errors - so it hard to guess the reason what's broken in my js code. Dmitriy

On Mon, 19 Mar 2012 00:40:54 -0700, Dmitriy Sintsov &lt;questpc(a)rambler.ru&gt; wrote: Autoloading classes is not possible. Even if every browser supported getters and we could use them to dynamically load classes, this would require synchronous http calls. Which are absolutely HORRIBLE because they block the entire JS thread and in addition typically even block the browser's UI. You shouldn't be dropping the closure, you don't want local things in the global scope. You also shouldn't be using the global $ and mw directly. Everything should be using a pattern like: ( function( $, mw ) { } )( jQuery, mediaWiki ); This is VERY bad JavaScript coding practice. Please use $.each(). I should really start poking people about this one. `"<div>" . wfMsg( 'foo' ) . "</div>"` is bad in PHP code, and it's just as bad inside JS. You should be creating your html with NO + concatenation, and then using a .find() and .text() to insert things where they belong. That, or use multiple $() calls with .append() to create the full structure. Likewise you shouldn;t be inserting this.Idx that way into the attribute. It should be added with something like .attr( "jqgmap_code" + this.Idx ); -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Mon, 19 Mar 2012 02:07:54 -0700, Dmitriy Sintsov &lt;questpc(a)rambler.ru&gt; wrote: RL doesn't know anything about loadEditPrototypes, I don't know what would make you think that it does. I can't really debug and say what's wrong without your code actually running somewhere. Completely wrong. for..in is object iteration. It is not to be used for array iteration. When you use for..in to iterate over an array you're actually iterating over object keys. Unset things may be left out, if there are any properties set you'll iterate over those when you shouldn't, if someone sets something on Array.prototype. (eg: Someone implements .forEach in an older browser) you'll iterate over that as well, and it's perfectly valid for a browser to iterate over the keys in an order that's different from the actual order of items in the array. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

<offtopic> On Mon, Mar 19, 2012 at 9:35 AM, Daniel Friesen &lt;lists(a)nadir-seen-fire.com&gt;wrote;wrote: This is rather exaggerated. Even more when looking at that suggestion. Arrays should, indeed, not be enumerated with a for-in loop. Arrays in JS can only contain numeral indices, so they should simply be iterated with a simple for-loop like this `for (i = 0; i < myArr.length; i += 1) { .. }` (maybe cache length for slight performance gain by reducing property lookups). Using $.each has overhead (+1+n function invocations). When given an array it will do a simple for-loop with a counter. It has overhead of 1+n additional function invocations and context creations. In most cases there is no use for it. There is one case where it is handy and that's when you specifically need a local context for the loop (being careful not to create later-called functions inside the loop, risking all variables being in the post-loop state). If you don't need a local scope for your loop, then using $.each (or the native [].forEach in later browsers) is pointless as it only has overhead of additional function invocations and lowering the position in the scope chain. When iterating over objects, however, (not arrays) then $.each is no better than a for-in loop because (contrary to what some people think) it is not a shortcut for for-in + if-hasOwn wrapper. When an object is passed, it literally just does a plain for-in loop invoking the callback with the value. jQuery does not support environments where someone extends the native Object.prototype because it is considered harmful (an therefore MediaWiki inherently does not support that either), so a plain for-in loop over an object (excluding array objects) is perfectly fine according to our conventions. See also http://stackoverflow.com/a/1198447/319266 .... but so much for the good (and bad, evil) parts of javascript :D -- Krinkle

* Krinkle &lt;krinklemail(a)gmail.com&gt; [Mon, 19 Mar 2012 14:32:51 +0100]: Converted all of for..in into $.each(). The most funny thing is that $.each() did not work correctly with sparse arrays [], walking with "undefs" between real elements. While for..in used to work fine (FF,Chrome,IE8,IE9). So I had to convert sparse arrays into sparse objects {}, just as you recommended. This way $.each() works, however it also creates new context (different "this") so I've had to use var myself = this more often than it used to be. The most pailful part was to pass control to the main module after edit module was abruptly terminated (without any warnings in Chrome console). I managed to call the main module method directly from edit module. Not a very nice thing, but at least it works. Who would know that such potentially easy thing as refactoring one js class into two ResourceLoader modules can be that much painful. I used to dynamically load jQuery for custom MediaWiki 1.15 installation via LABjs and don't remember such problems back then. Dmitriy

* Krinkle &lt;krinklemail(a)gmail.com&gt; [Wed, 21 Mar 2012 18:51:45 +0100]: not to 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. is 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. 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. 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. context), ResourceLoader". with that of 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

On Thu, 22 Mar 2012 00:15:40 -0700, Dmitriy Sintsov &lt;questpc(a)rambler.ru&gt; wrote: That's the very definition of an array. An array is a list, the keys are indexes. By definition you cannot have an index that does not exist. If an item in the array does not exist then the items after it take on earlier indexes and the length is shorter. If you have a case where 0 and 2 exists but 1 is not supposed to exist then you're not using an array, you're using a hashtable, map, etc... For that purpose you should be using Object like a hashtable: var h = {} h[0] = 'a'; h[2] = 'c'; You can use for..in on such a thing. And you also shouldn't have to worry about using hasOwnProperty on it. If anyone is stupid enough to set something on Object.prototype a lot more than your script will break. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Thu, 22 Mar 2012 03:22:10 -0700, Dmitriy Sintsov &lt;questpc(a)rambler.ru&gt; wrote: PHP arrays are not arrays at all. PHP's array() is a bastardized fusion of arrays and hash tables. But they insist on calling them arrays despite the hard fact that they are completely different from arrays in every other language. PHP's implementation of an array is in zend_hash.c it's a HashTable with ordered keys. I think I see some linked-list like code inside there that handles the ordering. When you use $x[0] in an array you are really looking up the value for the key "0". Hence you can actually have an "array" where 3 comes before 1. There's no real way to access the actual array indexes of a php 'array' besides when you use things like reset, next, array_splice, etc... $.each is useful for arrays when you don't want to write a full for ( var i ... blah blah or need a function scope to make closures work. $.each is only useful for objects if you want a function scope for closures. -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]

On Mon, 19 Mar 2012 06:23:13 -0700, Krinkle &lt;krinklemail(a)gmail.com&gt; wrote: There's nothing exaggerated about telling people not to use for..in to loop over arrays. for..in is object iteration, period. The $.each recommendation is because that IS our equivalent to foreach for arrays. Don't underestimate the developer distaste for writing stuff like this all the time: `for ( var i = 0, l = arr.length; i < l; i++ ) { var arr2 = arr[i]; for ( var j = 0, ll = arr2.length; j < ll; j++ ) { var item = arr2[j]; } }` I never said not to use numeric for loops. But there's no reason to ditch clean code. Micro-optimizations like these are pointless. Most arrays have under 100 elements. No matter what type of loop you use the time taken for the operation is negligible. More important is that the code is clean and easy to read and write. Unless you are working with 5000+ element arrays or working with really low level code doing things like parsing and highlighting code there's no real reason to micro-optimize. If we cared about efficiency at that level. We wouldn't be using any of jQuery's dom querying or dom creation functionality. dom operations are practically the slowest thing there is to work with and jQuery just adds overhead. Btw, ;) for..in is actually the least efficient way to loop, the only thing that is slower than for..in is for..in with hasOwnProperty: http://jsperf.com/loop-testx http://jsperf.com/loop-test-short -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]