[modules] Securable Modules show of hands
Kevin Dangoor
OK, as I see it the Securable Modules proposal has struck a very nice
balance of providing namespaced modules with a reasonable syntax and
even decent compatibility with the browser environment. It *is*
different from what browser JS programmers are used to. But, many JS
programmers who have worked on larger frontend systems have gotten
used to working in namespaces of one kind or another.
Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
list couldn't help but feel like the module loader was just a
scopeable version of dojo.require"
Tom Robinson has converted Jack to use an implementation, and the
modules and requires statements look pretty clean to me:
http://github.com/tlrobinson/jack/blob/5c50e5af8c8f620f324b105ba6efcbf55f19a2b7/lib/jack/handler.js
At this point, I'm +1 on Securable Modules. I'd like to get a sense of
where other people stand. To keep things neat, let's keep this thread
to +1 / 0 / -1 and discuss any remaining issues with the proposal in
separate threads. Restating objections in a separate thread is not a
bad idea, given how much traffic has gone by and how the module
proposal has changed over time.
Also, keep in mind everything does not need to be 100% perfect. What
we want is a good starting point and direction forward, and to me this
looks good.
Thanks to everyone involved for bringing modules to this point,
because they do literally sit underneath everything else we'll be
doing.
Kevin
--
Kevin Dangoor
work: http://labs.mozilla.com/
email: k...@blazingthings.com
blog: http://www.BlueSkyOnMars.com
Kris Zyp
Kris
geekfreak
George Moschovitis
On Feb 7, 5:05 am, Kevin Dangoor <dang...@gmail.com> wrote:
> https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
>
> OK, as I see it the Securable Modules proposal has struck a very nice
> balance of providing namespaced modules with a reasonable syntax and
> even decent compatibility with the browser environment. It *is*
> different from what browser JS programmers are used to. But, many JS
> programmers who have worked on larger frontend systems have gotten
> used to working in namespaces of one kind or another.
>
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
> list couldn't help but feel like the module loader was just a
> scopeable version of dojo.require"
>
> Tom Robinson has converted Jack to use an implementation, and the
> modules and requires statements look pretty clean to me:
>
Chris Zumbrunn
On Feb 7, 2009, at 4:05 , Kevin Dangoor wrote:
> https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
>
> [...] keep in mind everything does not need to be 100% perfect. What
> we want is a good starting point and direction forward, and to me this
> looks good.
+1
Chris
Eugene Lazutkin
On Feb 6, 9:05 pm, Kevin Dangoor <dang...@gmail.com> wrote:
> https://wiki.mozilla.org/ServerJS/Modules/SecurableModules
>
> OK, as I see it the Securable Modules proposal has struck a very nice
> balance of providing namespaced modules with a reasonable syntax and
> even decent compatibility with the browser environment. It *is*
> different from what browser JS programmers are used to. But, many JS
> programmers who have worked on larger frontend systems have gotten
> used to working in namespaces of one kind or another.
>
> Said Peter Higgins of Dojo on irc today: "i was reading over the sjs
> list couldn't help but feel like the module loader was just a
> scopeable version of dojo.require"
>
> Tom Robinson has converted Jack to use an implementation, and the
> modules and requires statements look pretty clean to me:
>
Wes Garland
--
Wesley W. Garland
Director, Product Development
PageMail, Inc.
+1 613 542 2787 x 102
Tom Robinson
Though I'd still like to see "include"/"import", and adding exports
properties to the module scope... otherwise you get a "+0.5" from me ;)
Patrick Mueller
On Feb 6, 2009, at 10:05 PM, Kevin Dangoor wrote:
> At this point, I'm +1 on Securable Modules. I'd like to get a sense of
> where other people stand. To keep things neat, let's keep this thread
> to +1 / 0 / -1 and discuss any remaining issues with the proposal in
> separate threads. Restating objections in a separate thread is not a
> bad idea, given how much traffic has gone by and how the module
> proposal has changed over time.
Patrick Mueller - http://muellerware.org/
Hannes Wallnoefer
Robert Cerny
Robert
