What didn't work for me with --
shindig.foo = function() {
return { 'bar': ... };
}();
... is that methods in the same namespace have to be all defined/implemented
in one file.
ie: it's fine if all gadgets.rpc.* is implemented in a file rpc.js, but not
fine when gadgets.util.* are implemented across different files/features
across core.util.dom, core.util.string, etc. When feature core.util pulls
all these files in, it will effectively stomp all the previously-defined
core.util.*.
The tendency has been to make libraries smaller and more focussed to what
they do, ie: this means breaking up features into sub-features. To do so, I
had to convert more-focussed core.util.[dom|string|...] to fully-defined
names. Unless the above style (with shindig.foo) doesn't have this
limitation (ie: can incrementally define more methods on top what has been
defined), I personally prefer the fully-defined names, for consistency.
2011/7/26 ๏̯͡๏ Jasvir Nagra <[email protected]>
> 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
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > >
> > >
> >
>
