I don't have a strong preference either way although it's nice when
reviewing code to have all the exported things exported once when they share
a scope full of private helpers and other state. It also helps convey when
the setup of a particular part of the object graph is done.
Eg.
shindig.foo = (function() {
// ... all the helper functions and shared state ...
...
return { bar: bar, baz: baz };
}();
// at this point I know from convention that shindig.foo is done being setup
and will have just "bar" and "baz"
vs.
shindig.foo.bar = function() { ... }
/// ... a lot of code later
shindig.foo.baz = function() { ... }
If the amount of code between shindig.foo and the return is long, I'd
suggest another alternative that I think has the advantage of both:
(function() {
// ... all the helper functions and shared state ...
shindig.foo = {
bar: bar,
baz: baz
}
})();
On Tue, Jul 26, 2011 at 2:19 PM, John Hjelmstad <[email protected]> wrote:
> 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
