With the model we're using with exportJs, you actually can't as easily do
that or wrap "singleton"/namespaced items, unless you . exportJs(...) is
injected after the closure.
function() {
foo.bar.baz = function() { }
}();
exportJs("foo.bar", [foo,foo.bar], {baz:"baz"});
Of course, you can if you also update the style guide to prepend window:
function() {
window.foo.bar.baz = function() { }
}();
...though that requirement seems a little awkward and verbose to me.
--j
On Tue, Jul 26, 2011 at 2:12 PM, Dan Dumont <[email protected]> wrote:
> As mentioned by Paul before you can define:
>
> function(){
> FooClass.prototype.method = function() { }
> FooClass.prototype.method2 = function() { }
> }();
>
> to get a local scope.
>
> I think this makes it easier to audit what must be included in an export.
> And when you come up for air soon, maybe we can talk about AMD format and
> what that brings to the table. :)
>
>
>
> From: John Hjelmstad <[email protected]>
> To: [email protected],
> Date: 07/26/2011 04:43 PM
> Subject: Re: javascript readability..
>
>
>
> I still prefer status quo, as it reads more like a proper class to me,
> while
> being less verbose and centralizing the exported method definitions in a
> single place.
>
> As well, this question's corollary is whether to convert all instantiable
> objects to the form:
>
> FooClass.prototype.method = function() { }
> FooClass.prototype.method2 = function() { }
>
> ...from:
> FooClass = function() {
> // private state
> function method() { }
> function method2() { }
> return {
> method: method,
> method2: method2
> };
> };
>
> On this note, I'm conflicted. I like having actual private state, but
> prototype-style is more efficient.
>
> Enough people have complained over time about each of the existing idioms
> though that I suppose I could go the other direction, if it's causing
> development trouble.
>
> --j
>
> On Tue, Jul 26, 2011 at 6:17 AM, Ryan J Baxter <[email protected]>
> wrote:
>
> > +1 As well, I think its easier to read.
> >
> > -Ryan
> >
> > Email: [email protected]
> > Phone: 978-899-3041
> > developerWorks Profile
> >
> >
> >
> > From: Dan Dumont/Westford/IBM@Lotus
> > To: [email protected],
> > Date: 07/26/2011 09:00 AM
> > Subject: Re: javascript readability..
> >
> >
> >
> > +1
> >
> >
> >
> > From: Paul Lindner <[email protected]>
> > To: [email protected],
> > Date: 07/26/2011 02:51 AM
> > Subject: javascript readability..
> >
> >
> >
> > Hi,
> >
> > I'm curious to know what people think about some of the idioms in the JS
> > code you find in shindig. There's an awful lot of stuff like this:
> >
> > shindig.foo = function(){
> > //...
> > var myFunction = function() {
> > }
> >
> > return {'foo': myFunction,
> > 'bar': function() {
> > return 'bar';
> > }};
> > }();
> >
> >
> > Just search for @member to see the various places.
> >
> > What would people think if we moved to fully defined names for
> > function/method definitions instead?
> >
> > You could still wrap this inside a closure if you wanted local scope:
> >
> > function() {
> > shindig.foo.foo = function() {
> > ...
> > }
> > shindig.foo.bar = function() {
> > ...
> > }
> > }();
> >
> > --
> > Paul Lindner -- [email protected] -- linkedin.com/in/plindner
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
