clarify strategy around extensions
Closed this issue · 3 comments
@snappizz, in #6 you state the belief that quarks should not extend anything. wslib still provides many other extensions - should these all be removed?
It would be good to align on the future of these extensions, and then document the plan. Thanks!
#6 was only because the extensions in question were conflicting with new methods added in sc 3.7, generating a lot of annoying warnings at startup. wslib's extensions were (iirc) perfectly compatible with the core additions.
the remark that quarks shouldnt extend anything is just my personal philosophy, and not a prescription for wslib. generally, it's not forward compatible and risks stepping on other peoples' toes, which is exactly what happened here. i think a valid exception would be if my quark is about blergs and i make an extension like SimpleNumber:asBlerg. nobody else is making a quark about blergs, so the risk of naming conflicts is negligible.
whether wslib wants to include extensions is up to wouter. wslib has a good amount of momentum so i don't think it's a great idea to suddenly remove stuff and break other people's code.
also, one thought -- if there are small features in here that seem really useful to the general sc user base, we can definitely talk about moving them into core.
Got it! Thanks a lot - that all makes perfect sense. I suppose there's a slight gray area with things like SimpleNumber.asNote since in theory there might be other quarks which could implement a similar conversion. But we can cross that bridge when we come to it :)