On Jan 2, 4:24 am, jemptymethod <[email protected]> wrote: > On Jan 2, 4:18 am, אריה גלזר <[email protected]> wrote: > > > On Sun, Jan 2, 2011 at 11:09 AM, jemptymethod <[email protected]>wrote: > > > > 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. > > > excatly my point - what justification is there for a second level of hiding? > > state should not be public. $public can access it via $private, but > instances of Module cannot access it directly
Ok, I think i understand better now what you're asking. Why nest state inside of $private? It could be a var at the same level of $private, and still be accessible to $public, but not accessible to instances of Module The way I've structured it, Module has precisely two top-level members, $private, accessible only to the (public) interface, which the module returns. This to me seems to be the essence of a module. Furthermore, since Module is an immediately executing function, not allowing any code to execute except within nested closures, seems to give the best chance of adhering to the "Principle of Least Surprise". -- 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]
