Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement for all immutablejs types #16

Open
goodmind opened this issue Apr 11, 2018 · 2 comments
Open

Implement for all immutablejs types #16

goodmind opened this issue Apr 11, 2018 · 2 comments

Comments

@goodmind
Copy link

If all immutablejs types are extended from Collection can't we just patch it with fantasy-land methods?

@DrBoolean
Copy link
Owner

That's a good idea for aliases, but i'd think the implementation differs for most datatypes. In any case, a cool thing to try!

@StevenLangbroek
Copy link

StevenLangbroek commented Feb 10, 2019

I'm not sure what you're suggesting is a good idea. @DrBoolean is obviously right that the semantics differ per class. I think you can find good literature that centralizing logic that should be decentralized leads to all sorts of antipatterns (the least of which is having a single union that handles all cases). It'll become the highest traffic file in this repo and, unless you want a couple hundred line file, will still have to delegate to modules per class, making it something akin to a leaky abstraction...

edit: dig a little deeper before commenting Steven 😞. So this repo lives in a single file, so that concern isn't relevant (not until the repo grows a lot anyway). That being said, that union or switch or whatever structure you use for the logic would still live in Collection.prototype.<methodName>, which would still be a code smell.

I'd still like to contribute, I could whip up a table of structures, the algebrae they implement, some notes so that people can pick them for contribution?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants