search

mozilla / node-firefox

node.js modules for interacting with Firefox via the DevTools remote protocol
https://www.npmjs.org/package/firefox
Mozilla Public License 2.0
301 stars 18 forks source link

A discussion on the type of objects we pass around #15

Open sole opened 9 years ago

sole commented 9 years ago

We often handle the same type of "objects" when using modules in this project. They're sometimes not actual classes but just simple Objects with the same set of consistent attributes all over. A thought that often passes my mind is whether we should elevate them to their own class so we can say in the API "This call returns an object of class XYZ".

Or whether we should maybe use those objects instead of some of their properties, and hide them in the most generic case.

For example, if start-simulator would return an instance of Simulator option instead of returning a simple object, then we could also pass said instance to connect, instead of passing a port number, which requires you to know the name of the field (.port).

I have to write other modules now but I wanted to leave this here before I forget or move to another thing. I might come back with more thoughts/examples. Feel free to discuss/tell me why/if I'm wrong here :-)

tofumatt commented 9 years ago

In general I like the idea that we can pass simple JS objects around. Seems this would either be a behind-the-scenes increase in complexity (converting objects to fancyObjects) or would require making a new Simulator() instead of just calling a function.

I’m not religiously opposed to the idea or anything. I can see what you mean and how it might actually be a lot better, but I’d want to see a real-world example of how it would reduce code complexity before I would say it’s a good idea. :-)

-tofumatt

On 26 January 2015 at 16:45:15, sole (notifications@github.com) wrote:

We often handle the same type of "objects" when using modules in this project. They're sometimes not actual classes but just simple Objects with the same set of consistent attributes all over. A thought that often passes my mind is whether we should elevate them to their own class so we can say in the API "This call returns an object of class XYZ".

Or whether we should maybe use those objects instead of some of their properties, and hide them in the most generic case.

For example, if start-simulator would return an instance of Simulator option instead of returning a simple object, then we could also pass said instance to connect, instead of passing a port number, which requires you to know the name of the field (.port).

I have to write other modules now but I wanted to leave this here before I forget or move to another thing. I might come back with more thoughts/examples. Feel free to discuss/tell me why/if I'm wrong here :-)

— Reply to this email directly or view it on GitHub.

MattiSG commented 9 years ago

If you have shared objects with shared behavior, consider putting them in their own class and packaging the class as a module that all dependents will import.

If you're just passing around structured data, then you're only using Object as a map, and you'll be better off using a documented POJO, as that will make serialization completely painless, saving you time when you want to transfer that data over the wire (which will inevitably happen at some point).