Dolhon: Though it’s ugly as sin

Kilbane: Anyone know a good guide on allowing plugins into my library?

Whitelow: Schimming: for arguments, the best optimisation is not creating it in the first place :

Acuna: Slide: what aspect of it? i think there are a few decent books on plugin architectures.

Trucchi: Oh, it’s only created if referenced? I guess that makes sense

Jurist: Straight: nope, v8 refuses to optimize functions that call other functions with arguments

Crider: Even if its Array.prototype.slice.call

Haakenstad: At least, as of node 4.0.0

Wesby: Slide: or maybe not, maybe it was in a dream : that said, real-world examples abound and elements of plugin systems are described in most design books

Harklerode: Trucchi: since it’s a dynamic variable, it’s very easy to do that ****ysis

Kilbane: Bertot, well, right now the bigger problem I have is my main library is using the “Revealing Module Pattern” however that doesn’t allow any ‘plugin’ access to its ‘private’ methods etc

Klippel: And a, .rest = f.rest now makes arguments pretty much useless

Board: Slide: that’s API design for you : don’t make stuff private that needs to be public

Bodie: Slide: sounds like you want to rethink your plugin API?

Kilbane: Hrm but I dont *want* it public lol.

Alukonis: Who are the plugin authors?

Padiong: Well it doesn’t actually have to be public

Rybowiak: You can do whatever internally and explicitly expose some API

Kilbane: I need 1 main very lightweight library that is loaded on a client, then I need to be able to extend it to do the backend stuff/visualization etc

Kilbane: And by backend I mean on the backend web page, not server side

Maura: Take a break and a walk around your nearest enclosed body of water : it sounds like you have some structure in place and are hesitant to modify it

Gulke: It sounds like you need to rework the API though to be friendly for plugin development and rethink stuff you’re keeping private

Kilbane: Nah, just not sure how to modify it. I don’t want the main thin library to really be ‘extensable’ to the public at large

Kanzenbach: If the plugins are private, define them in a private context

Kilbane: Just extensible by me hah

Trible: Where they can access the naughty bits

Meltzner: It sounds like you’re overthinking this

Tuai: Anyway these are just the nuts and bolts of API design, i’m sure you’ll figure it out

Guidi: If you’re the only one it needs to be extensible to, then just do what you are most comfortable with.

Canzoneri: It’s always a balance

Selby: I’d just make more stuff public internally and explicitly export some API

Kyser: No shame, do you have a java background perchance?

Carico: Slide: forgetting all you’ve learned in Java is probably the fastest way of getting good at JS.

Silvestro: Slide: data privacy isn’t held in as high regard in JS world. we’re still figuring out packaging : but strategies for exposing data/functionality in java are just as applicable in JS. just make sure you know how to precisely control privacy in different contexts

Starken: They’re a pretty bad idea ime

Stephanie: It’s actually pretty rare that i make things private. in any language. i used to be more gung ho about it but honestly i’ve had more headaches due to over encapsulating things than i have from, idk, whatever terrible things people say happens if you use a lot of public fields.

Piccinone: And access policies aren’t actually a good idea, in general, ime. Whether you’re writing it in Java or any other language

Dwan: Slide: for instance hiding constructors is just as useful in JS as in Java and is done the same way except you can’t actually make the constructor function private in the same way

Beese: Not to mention that they have very iffy composition semantics in Java