Extension of built-in native objects in recipes
fhemberger opened this issue · 8 comments
Browsing the recipes, I found one pattern to be quite common: The extension of build-in native objects.
It's totally fine to back-port ECMAScript 5 methods (as long you make sure, you don't overwrite existing implementations by accident), e.g.:
unless String::trim then String::trim = -> @replace /^\s+|\s+$/g, ""
On the other hand, modifying objects you don't own is considered a bad practice in JavaScript (whereas it's quite common in other languages like Ruby):
- Maintainable JavaScript: Don’t modify objects you don’t own by Nicholas C. Zakas
- Extending built-in native objects. Evil or not?
Personally, I think those examples should either be reworked or have a note in the "Discussion" section, that this should be used with caution, linking the articles above.
What do you think?
I think it sounds very reasonable to have note about this in the discussion section.
I agree, but why are you asking me? It's not my project.
Jeff Pickhardt
Sent from my Android
On Feb 23, 2012 4:10 AM, "Frederic Hemberger" <
reply@reply.github.com>
wrote:
Browsing the recipes, I found one pattern to be quite common: The
extension of build-in native objects.
It's totally fine to back-port ECMAScript 5 methods (as long you make
sure, you don't overwrite existing implementations by accident), e.g.:unless String::trim then String::trim = -> @replace /^\s+|\s+$/g, ""On the other hand, modifying objects you don't own is considered a bad
practice in JavaScript (whereas it's quite common in other languages like
Ruby):
- Maintainable JavaScript: Dont modify objects you dont own
by Nicholas C. Zakas- Extending built-in native objects. Evil or not?
Personally, I think those examples should either be reworked or have a
note in the "Discussion" section, that this should be used with caution,
linking the articles above.What do you think?
Reply to this email directly or view it on GitHub:
@pickhardt Issues filed for a group project are forwarded to every member.
Oh, didn't realize that I was a member, thanks.
Jeff Pickhardt
pickhardt@gmail.com
On Thu, Feb 23, 2012 at 4:10 AM, Frederic Hemberger <
reply@reply.github.com
wrote:
Browsing the recipes, I found one pattern to be quite common: The
extension of build-in native objects.
It's totally fine to back-port ECMAScript 5 methods (as long you make
sure, you don't overwrite existing implementations by accident), e.g.:unless String::trim then String::trim = -> @replace /^\s+|\s+$/g, ""On the other hand, modifying objects you don't own is considered a bad
practice in JavaScript (whereas it's quite common in other languages like
Ruby):
- Maintainable JavaScript: Dont modify objects you dont own
by Nicholas C. Zakas- Extending built-in native objects. Evil or not?
Personally, I think those examples should either be reworked or have a
note in the "Discussion" section, that this should be used with caution,
linking the articles above.What do you think?
Reply to this email directly or view it on GitHub:
I think this is reasonable point and request. I wrote this originally, but just put it together based on the TODO list of wanted recipes. I don't have time right now, but I'll make a note to update this chapter in the near future if no one gets to it first :)
Eh, I don't think it's an issue, and in any case it seems orthogonal to the concerns of coffeescript-cookbook :)
On 23/02/2012, at 23:10, Frederic Hembergerreply@reply.github.com wrote:
Browsing the recipes, I found one pattern to be quite common: The extension of build-in native objects.
It's totally fine to back-port ECMAScript 5 methods (as long you make sure, you don't overwrite existing implementations by accident), e.g.:unless String::trim then String::trim = -> @replace /^\s+|\s+$/g, ""
On the other hand, modifying objects you don't own is considered a bad practice in JavaScript (whereas it's quite common in other languages like Ruby):
- Maintainable JavaScript: Don’t modify objects you don’t own by Nicholas C. Zakas
- Extending built-in native objects. Evil or not?
Personally, I think those examples should either be reworked or have a note in the "Discussion" section, that this should be used with caution, linking the articles above.
What do you think?
Reply to this email directly or view it on GitHub:
#38
@nornagon Thought the concerns would be providing best practices …
I'll add this under "discussion" as a word of caution. If a user goes with it or not remains completely up to him.