Posts by ShatteredMotion

    And this is what i do NOT want, as people can forget their e-mail-adress!

    And then what? Even when they enter their username, they still receive an email to actually confirm the password request. When they don't know which email address they used, they can't perform a password reset with their username, either. Unless they then go through all their email adresses and search for the mail. But then they could just as well try all their adresses in the form until one matches.

    The WSC is free and open source, while the moderated user groups require a license to be used. WoltLab obviously didn't want to provide this functionality for free, therefore it couldn't be integrated into the framework.

    Likewise, it's a separate plugin and not part of the forum software because customers not using the board but any other sold product (filebase, gallery etc.) may use the plugin.

    Having a unified pattern is more important than applying micro-optimizations where the difference can only be measured by comparing CPU cycles.

    I disagree here. Currently only one line, or more precise, the new keyword, highlights whether just a collection of functions (singleton) is returned or that the developer has to create an instance of an object type. The object literal would make it perfectly clear how other developers have to work with that module at first glance.

    Unless you're inlining the _click function directly and using something among the lines of var self = this; to abuse scoping, how do you want to preserve the this context? Also the examples above are just examples, in a real-world code where I expect the handler to be bound to a lot of elements I would store the bound callback in a variable instead to decrease the payload of binding with each iteration.

    Just to make it clear, I talk about something along the lines of the third code snipped here: http://usejsdoc.org/tags-exports.html
    Inside your addEventListener call, you can reference to the handler by FooBar._click (or still use this since it would point to FooBar anyway). Or, if you like, make the handler function correctly private by not assigning it to the returned object in first place.
    However, in the handler you can replace all current this calls with FooBar and remove the explicit binding in addEventListener.
    We talk about a singleton here, there is no point in using this in first place since there is only exactly one instance anyway, which you can (and probably should) easily store in an ordinary variable.

    Is there a special reason for the rather complex singleton pattern with overwriting the function prototype and new in the second code snippet? A simple object literal would be sufficient and way more performant (though it probably wouldn't matter in the framework's use cases, I suppose).
    Moreover, since you specifically pointed out the reduced bounding calls, you could thereby remove this from that piece of code altogether and remove the bind call for the click handler as well.