sanctuary-js / sanctuary

:see_no_evil: Refuge from unsafe JavaScript
https://sanctuary.js.org
MIT License
3.03k stars 94 forks source link

How costly is to create a sanctuary instance #567

Closed danielo515 closed 6 years ago

danielo515 commented 6 years ago

Hello,

I am going to create a package for internal use on my company that encapsulates sanctuary. To make things easier to my co-workers I want to export a sanctuary version that only performs type checking on production by default. However, I want to provide an easy way for using some functions that perform type-checking even on production, so you can choose which one to use. Take some allways safe functions for certain parts and non-checking functions for the rest.

My question is, how costly is to bootstrap a sanctuary instance ? My idea is to make something like this:

const sanctuary = create ({ checkTypes: isProd, env });
const sanctuarySafe = create ({ checkTypes: true, env });

module.exports = { sanctuary , sanctuarySafe };

My main concern is about memory, because bootstrap time I understand that is negligible. If it is too costly to make it by default, I can always encapsulate the second option on a thunk, and require users to execute it to actually get the bootstrapping.

Thanks in advance.

davidchambers commented 6 years ago

My question is, how costly is to bootstrap a sanctuary instance ?

The cost is negligible, I imagine. The implementations are defined exactly once, so the cost of creating a Sanctuary module is equal to the sum of the costs of wrapping the various implementation functions.

const sanctuary = create ({ checkTypes: isProd, env });

If isProd is defined as process.env.NODE_ENV === 'production' and env is defined as S.env, you could use the default Sanctuary module here.

danielo515 commented 6 years ago

Hello @davidchambers ,

I ended wrapping the always safe version on a thunk that bootstraps it, to avoid bootstrapping it when not needed.

I'm not sure I understand your second comment. Do you mean that by default sanctuary will look for NODE_ENV and deactivate the runtime-type-checking accordingly and that it will use the default env from S.env ? Does that mean that If I run create myself I am actually doing the same twice ?

davidchambers commented 6 years ago

Do you mean that by default sanctuary will look for NODE_ENV and deactivate the runtime-type-checking accordingly and that it will use the default env from S.env ?

Yes. This change was made in #512. I must write the release notes for v0.15.0 to document this.

Does that mean that If I run create myself I am actually doing the same twice ?

Yes. You will need to use S.create if you want to specify a different rule for when type checking should be enabled and/or include different types in the environment.

danielo515 commented 6 years ago

Yes. You will need to use S.create if you want to specify a different rule for when type checking should be enabled and/or include different types in the environment.

But then, whatever I do, the creation is being executed at least once ? Let's say that I want to add some extra env to my custom sanctuary build, does that mean that I will have my custom one and the default one exported by sanctuary ?

davidchambers commented 6 years ago

Let's say that I want to add some extra env to my custom sanctuary build, does that mean that I will have my custom one and the default one exported by sanctuary ?

Yes. In fact, Sanctuary exports two modules: S itself, and S.unchecked.

danielo515 commented 6 years ago

Yes, I noticed about the unchecked one. Thanks for your clarifications. They make a lot of sense for the default case I have to say. At first encapsulating sanctuary into our own internal library was to make it's usage easier. I didn't wanted that my coworkers had to take the responsibility of activating and deactivating type checking based on the environment. Thankfully it still makes sense because now I customize sanctuary with some custom types and I also export some utility functions. But the behavior you described is not obvious, and I think you should clarify it on the documentation. Maybe a small note on the creation example where you do it based on node env would be enough. Something like: please note this is the default behavior.

Regards

davidchambers commented 6 years ago

But the behavior you described is not obvious, and I think you should clarify it on the documentation. Maybe a small note on the creation example where you do it based on node env would be enough.

Is the following sufficient?

There is a performance cost to run-time type checking. Type checking is disabled by default if process.env.NODE_ENV is 'production'.

danielo515 commented 6 years ago

Is that on the documentation already? I totally overlooked it

davidchambers commented 6 years ago

It was added within the past two weeks. :)

danielo515 commented 6 years ago

OOO, that makes sense 😄