On Jan 2, 2:49 am, אריה גלזר <[email protected]> wrote: > I'm not sure you understood my question - > If all the private scope does is being run on construction, there's no > reason to give it an object. the whole point of using a closure is that you > can create "private" methods. > The way I understand public/private concept is that you create a distinction > between the interface and the inner behavior. but the interface itself can > and should have access to the private interface internally. > 2nd, at least wherever I've been programming, unless we use a singelton > pattern (which is unnecessary in JS), the constructor is public and can > usually be called again and again. IMO - this is not a bug. > So what I don't understand is what use do you get from the 2nd private > closure? why create a 2nd layer encapsulation? what good is it? > so again - what advantages does this pattern have vs the original module > pattern?
None of the code within the module closure executes outside of the context of either the closure that set $private, or the closure that returns $public. Including the state, which can only be accessed via private. > Lastly - I agree with the previous post that stated that UpperCase is for > constructors, and your template clearly doesn't allow the use of new. I didn't go through the trouble of contriving an entire namespace, but that is ordinarily how you would access a module, as in the yui blog entry I referenced: http://www.yuiblog.com/blog/2007/06/12/module-pattern/ Admittedly the trailing portion of the name of the module there is lower case: YAHOO.myProject.myModule Nevertheless the problem with conventions are they are just that: mere conventions. Within a namespace I personally have no problem with the trailing name being capitalized, so I would be comfortable redefining the above as: YAHOO.myProject.MyModule. I think a better convention than relying on initial capitalization is, like my usage of $private and $public, to make it glaringly obvious, perhaps something such as the following, based on a project I'm currently working on, where "IM.RC2" has already been defined: IM.RC2.App = {}; IM.RC2.XType = {}; //for custom ExtJS xtypes IM.RC2.Constructor = {}; //for "domain object" constructors Then when you have constructors such as IM.RC2.Constructor.Cart or IM.RC2.Constructor.Item it is glaringly obvious. Then a relative newcomer to Javascript, who at least has learned about inherent functionality of functions being able to be used as constructors, doesn't also need to know useless conventions. My method of having all code within my modules execute within inner closure is, of course, a convention I choose. Others apparently don't find it particularly efficacious. Thanks everybody for your feedback. -- To view archived discussions from the original JSMentors Mailman list: http://www.mail-archive.com/[email protected]/ To search via a non-Google archive, visit here: http://www.mail-archive.com/[email protected]/ To unsubscribe from this group, send email to [email protected]
