Re: A proposal for Element constructors
This proposal sounds very interesting. On Wed, Oct 26, 2011 at 5:54 AM, Adam Barth w...@adambarth.com wrote: Another solution to that more than one tag per interface problem is to introduce subclasses of those interfaces for each tag. +1 Julien
Gave a try to the Component Model
Hi, I’m interested in the component model proposal [1] and tried to imagine what architecture patterns our apps would follow by using it. I wrote my notes here [2] and I’d like you to read and comment them. The most difficult problem to solve seems to be the way components will be bound together since we don’t control how they are instanciated and configured. Regards, Julien [1] http://wiki.whatwg.org/wiki/Component_Model [2] http://substance.io/julienrf/dom-component-model/1
Re: Notes from a component model pow-wow
Hi, If I understand correctly you are planing to allow shadow dom to be styled by users stylesheets. I’m not sure it will be a good idea since it would break encapsulation. Regards, Julien
Re: [selectors-api] Return an Array instead of a static NodeList
On Aug 30, 2011, at 10:33 AM, Jonas Sicking wrote: My point was that it was a mistake for querySelectorAll to return a NodeList. It should have returned an Array. Sounds like people agree with that then? I think it’s better to return an immutable object (mutable objects are source of programming errors). But this immutable object should have traversing method (forEach, map, filter, etc.). Julien.
Re: [selectors-api] Return an Array instead of a static NodeList
On 30 août 2011, at 18:07, Jonas Sicking jo...@sicking.cc wrote: On Tue, Aug 30, 2011 at 2:32 AM, Julien Richard-Foy jul...@richard-foy.fr wrote: I think it’s better to return an immutable object (mutable objects are source of programming errors). But this immutable object should have traversing method (forEach, map, filter, etc.). Can you explain how mutable objects are a source of programming errors. It seems that javascript made the choice a log time ago to use mutable objects and settable variables, as opposed to for example haskell. Sure, have a look to these links: http://en.m.wikipedia.org/wiki/Immutable_object http://ofps.oreilly.com/titles/9780596155957/FunctionalProgramming.html But that's not so important. If you just add traversing methods to NodeList it would be a huge improvement.
Re: [selectors-api] Return an Array instead of a static NodeList
That works, but what is the advantage? And .push/.pop or other mutating functions wouldn't work. All mutable functions will work (forEach, map, etc.) and bring a better expressiveness to the code. Not if he 'this' object is a NodeList. Yes, sorry I meant all “immutable” functions will work. Julien
Re: [selectors-api] Return an Array instead of a static NodeList
On 25 août 2011, at 08:33, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 24, 2011 at 12:04 PM, Aryeh Gregor a...@aryeh.name wrote: On Wed, Aug 24, 2011 at 1:27 PM, Jonas Sicking jo...@sicking.cc wrote: I agree with this, but it might be too late to make this change. The problem is that if we returned an Array object, it would not have a .item function, which the currently returned NodeList has. I guess we could return a Array object and add a .item function to it. Or return a NodeList and add .forEach/.filter/etc. to it? That works, but what is the advantage? And .push/.pop or other mutating functions wouldn't work. All mutable functions will work (forEach, map, etc.) and bring a better expressiveness to the code.
[selectors-api] Return an Array instead of a static NodeList
Since Javascript 1.6, a lot of useful collection functions are defined for Array [1]. Unfortunately, they can’t be used directly with results returned by .querySelectorAll, or even .getElementsByTagName since these functions return NodeLists. I understand the DOM API is defined without a language in mind, but these collection functions are really useful, easy to implement and already available in most mainstream languages. Therefore, why not create a base Traversable type which would be implemented by all collection types (like NodeList) and which would provide the so useful bunch of iteration methods? Are there some issues or drawbacks I did not think of? Regards, Julien [1] https://developer.mozilla.org/en/JavaScript/Reference/Global_Objects/Array#Iteration_methods
