clientside global namespace pollution about plates

[heapwolf]

All libraries generally use at least one object in the global namespace. Its perfectly acceptable for an application to have a few variables in the global namespace, since the application developer has oversight into the involved components.

Conversely, it is potentially dangerous for a library to increase the surface area of the global namespace, since a library author has no idea what other variables will already be there. The constructor Plates is a pretty safe name.

[Phoscur]

Okay, maybe the topic name is not correctly chosen.

My problem is that you are mixing node specific code with that global variable creation. And when you use a tool like browserify to include plates, you lose plates in the wrapping it creates.
This is a case where Plates should export on exports, but process is not defined.
Please use:

;var Plates = !exports ? {} : exports;

or

;var Plates = (!module && !exports) ? {} : exports;

Reopen!

[heapwolf]

The problem with this is that its far too likely for exports or module to be defined in the user's global namespace. Alternatives?

[Phoscur]

At include time? That sounds like some pretty bad style of polluting the global namespace, who does that? Ofc my proposal is not idiotproof.

;var Plates = (typeof require == 'function' && module && exports) ? exports : {};

[heapwolf]

I think we are crossing wires. I am talking about the client side. The client side it is very easy for someone to have those variables defined. Of course its bad style, but its more likely than an object named process with a property called title. Someone can also have a client side function called require... Let's think about it some more.

[Phoscur]

Well IMO using Plates and having a require function and module and exports objects is basically as unlikely as having a process object with a title containing "node". Also this risk is far less important than the drawback it has.

An alternative way to go would be giving out different files for browser and nodejs use.

Let's think about it some more.

Why isn't this open then?

[heapwolf]

A library that exports a single global object does not polluting the global namespace. If you are concerned about browserify please create a test that demonstrates the issue.

[Phoscur]

It's pretty simple what browserify does:
warp a function around Plates

function(require, module, exports, __dirname, __filename) {
var Plates = {}
[...]
}

execute the function -> oh noes, Plates got garbage collected.

I think I'm just going to fork Plates and stop annoying you.

[heapwolf]

I know what browserify does, i asked you to write a test for it. If you cant make a tangible case for your issue i cant help.

[Phoscur]

I don't really have any idea how a test for this should look like.