Extension of built-in native objects in recipes

[fhemberger]

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?

[peterhellberg]

I think it sounds very reasonable to have note about this in the discussion section.

[pickhardt]

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:

#38

[fhemberger]

@pickhardt Issues filed for a group project are forwarded to every member.

[pickhardt]

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:

#38

[phlipper]

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 :)

[nornagon]

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

[fhemberger]

@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.

[fhemberger]

Fixed by 5e7fe47.
(Typo in the commit message, has nothing to do with #1)