All members assigned to the prototype would automatically be available.
You'd use pretty much the same syntax, but you wouldn't need to reference
the full package name for each member:

some.package.SomeClass = (function()
{
    var SomeClass = function(){};
    SomeClass.prototype.someMethod = function()
    {
    };
    return SomeClass;
})();

You wouldn't be able to define the methods outside of the IIFE, since they
wouldn't be able to access any private classes inside the IIFE.

I just checked how TypeScript handles modules, and they use the same
technique, with a slight variation on how the package/module is assigned.
Here's similar TypeScript:

//TypeScript
module some.package {
    export class SomeClass {
        constructor() {
        }
        someMethod() {
        }
    }
}

And here's the generated JavaScript:

//JavaScript
var some;
(function (some) {
    var package;
    (function (package) {
        var SomeClass = (function () {
            function SomeClass() {
            }
            SomeClass.prototype.someMethod = function () {
            };
            return SomeClass;
        })();
        package.SomeClass = SomeClass;
    })(package = some.package || (some.package = {}));
})(some || (some = {}));

The main difference is that it passes in the objects used to define the
package/module as arguments rather than assigning them completely outside
of the function. I don't know what your concerns are for the compiler work
required, but maybe that would make a difference.

- Josh

On Mon, Nov 16, 2015 at 12:07 PM, Alex Harui <aha...@adobe.com> wrote:

>
>
> On 11/16/15, 10:36 AM, "Josh Tynjala" <joshtynj...@gmail.com> wrote:
>
> >The Immediately-Invoked Function Expression (IIFE) pattern could be used
> >to
> >create private classes.
> >
> >some.package.SomeClass = (function()
> >{
> >    var SomeHelperClass = function(){};
> >
> >    var SomeClass = function(){};
> >
> >    return SomeClass;
> >})();
> >
> >SomeHelperClass will only be accessible inside the (function(){}).
> >SomeClass will be returned to allow it to be exposed externally. It's a
> >pretty common pattern in JavaScript to avoid polluting the global
> >namespace.
>
> Thanks for the suggestion.  Would that work for method access?  For
> example:
>
> package some.package
> {
>    public class SomeClass
>    {
>       public method someMethod()
>       {
>         var foo:SomeHelperClass = new SomeHelperClass();
>       }
>    }
> }
>
> class SomeHelperClass
> {
> }
>
>
>
> Right now, someMethod is generated as:
>
> some.package.SomeClass.prototype.someMethod = function()
> {
> }
>
> Would it have to go within the outer function?  That might be a lot of
> compiler work.
>
> -Alex
>
>

Reply via email to