tag:blogger.com,1999:blog-19002723.post8152429453151380540..comments2023-02-21T00:14:00.325-08:00Comments on Tagneto: Namespaces, Subjects and Verbs in JavaScriptJameshttp://www.blogger.com/profile/12067100302830600925noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-19002723.post-32677654231558736032009-04-03T20:21:00.000-07:002009-04-03T20:21:00.000-07:00Alex, my first thought is that we do not need a se...Alex, my first thought is that we do not need a separate Element API. <BR/><BR/>What I would like to see for all the getter methods on NodeList, if the NodeList has one element, just return the value not as an array but as the getter value.<BR/><BR/>I think this gets to your developer productivity desires, and similar conversations we have had about dojo.create: it is OK if the return type might be different things in different contexts, the context will be obvious for the developer.<BR/><BR/>One reason to do an Element API may be performance. However, Element should have the same API as the NodeList API, and the Element type should be interoperable with NodeLists, being able to add them to each other would be nice. <BR/><BR/>But the performance gain would have to be awesome and the Element implementation size would have to be tiny for it to be worth it.<BR/><BR/>I would rather see us optimize the NodeList operations as much as possible. Maybe we can fast-path the NodeList operations if there is only one node in the list. If we can do that magic in the adaptAs* functions Eugene added, that might be enough of a speed benefit/implementation size tradeoff to avoid the Element construct.James Burkehttps://www.blogger.com/profile/00451746837849321739noreply@blogger.comtag:blogger.com,1999:blog-19002723.post-61516237850615289852009-04-03T19:19:00.000-07:002009-04-03T19:19:00.000-07:00This is a great analysis. It really clarifies a lo...This is a great analysis. It really clarifies a lot for me.<BR/><BR/>It really does seem clear that the language-intrinsic bits of Dojo are one namespace and we try to unify to that (e.g., connect()), while the DOM/NodeList bits are a different set with different normalized behaviors. Related but different, and giving them different top-level entry points might be a nice way to end the war.<BR/><BR/>One of the things that's still left lingering in my mind is the difference (if there should be one) between singles and multiples. For dojo.NodeList(), we deal in multiple items, whereas other APIs which are lower level all deal (explicitly) with single elements. Dojo hasn't had an Element class for various reasons, and it seems that Element is a 3rd namespace, or at least a flattened version of the NodeList "thing". Getting to a common view between Elements and NodeLists strikes me as the missing link which would allow Dijit to have an abstraction that springs directly from Core.<BR/><BR/>Dunno. What do you think?Unknownhttps://www.blogger.com/profile/11981572061141304573noreply@blogger.com