Comments (3)
It's unlikely, I disagree with ever extending a built-in prototype. If you want you can just assign it yourself and write a wrapper. E.g.
var changeCase = require('change-case');
for (var key in changeCase) {
String.prototype[key] = function () {
return changeCase[key](this);
};
}
from change-case.
I value perspective. Would you be willing to share why you avoid extending? Is it because other modules might collide and cause issues? Thanks!
from change-case.
Yeah, no problem. There are a couple of things and collisions are definitely valid. It basically comes down to if I wanted to extend someone elses code with my own - I would subclass it to ensure greater compatibility. It also means that other people that use the code aren't startled when this random bit of code is inside something they are using.
Although this isn't as specific as other things, I believe the rule should be fully enforced everywhere. That way no one has any surprises and the original authors can continue building up their code without having to worry about downstream consumers.
from change-case.
Related Issues (20)
- Please restore CJS support HOT 8
- Import failing after upgrade to v5 HOT 26
- `This Is A Title` vs `This Is a Title` HOT 1
- title-case does not correct any words containing "wrongly" capitalized words. Intended behavior? HOT 5
- Not working for me HOT 9
- Failing after upgrade to v5 HOT 2
- Newest Update broke our pipelines HOT 1
- Bug with case conversions for snake case with numbers HOT 4
- Parcel build fails HOT 7
- Upgrading from `[email protected]` to `[email protected]` results in a "Cannot find module" error while testing HOT 1
- How to migrate to v5 from v4? HOT 3
- splitRegexp removed in v5? HOT 8
- Finer tuning of split separator? HOT 5
- use `DRAGON_CASE` - because of env vars HOT 6
- wish you hadn't changed the export setup and added this confusing subpackage thing HOT 1
- Postfixing characters HOT 1
- First word after colon not capitalized HOT 2
- Case Transformations Remove Punctuation HOT 4
- Package subpath './keys' is not defined by "exports" HOT 6
- I tried to migrate from camel-case to change-case and see this error HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from change-case.