Envjs envjs

Comments and changes to this ticket

• 

  Thatcher March 29th, 2010 @ 03:22 PM

  Theres really not a good reason to include a file more than 10 line twice.
  In fact all of the file included mutliple times might as well become methods
  of envjs. extend was a bad example to try to reuse.

  Does that seem reasonable to you too?

• 

  nickg March 29th, 2010 @ 03:26 PM

  agreed: all those small functions should be a method of Envjs. Most of those are utilities anyways. And trim actually might want to be overridden (rhino oddly doesn't have string.trim, while spidermonkey, others have it natively).

  What about bigger files like urlparse.js and aspect.js?

  --nickg

• 

  Thatcher March 29th, 2010 @ 04:14 PM

  Also Envjs.functions i guess. we could go back to making Envjs it's own
  closure so some bigger routine can be encapuslated. It's sort of 6 one way,
  1/2 dozen the other. I'm almost dug out of my open source back logs, the
  way-over-due stuff anyway, but I'm not a control freak so I'll let you and
  the team decide whats best. The good thing about putting it inside the
  Envjs closure is that we can abstract the implementation, but my opinion is
  once its pure js-ish it might as well be directly on Envjs since that's
  basically our goal.