Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #29170 > unrolled thread
| Started by | Simon Blackwell <syblackwell@anywhichway.com> |
|---|---|
| First post | 2016-01-07 14:29 -0800 |
| Last post | 2016-01-09 21:49 -0300 |
| Articles | 4 on this page of 24 — 7 participants |
Back to article view | Back to comp.lang.javascript
Javascript Object Extensions Updated Simon Blackwell <syblackwell@anywhichway.com> - 2016-01-07 14:29 -0800
Re: Javascript Object Extensions Updated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-07 14:45 -0800
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-07 21:37 -0300
Re: Javascript Object Extensions Updated Joao Rodrigues <groups_jr-1@yahoo.com.br> - 2016-01-07 17:43 -0800
Re: Javascript Object Extensions Updated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-07 18:03 -0800
Re: Javascript Object Extensions Updated Simon Blackwell <syblackwell@anywhichway.com> - 2016-01-09 05:54 -0800
Re: Javascript Object Extensions Updated Simon Blackwell <syblackwell@anywhichway.com> - 2016-01-09 06:12 -0800
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-09 12:27 -0300
Re: Javascript Object Extensions Updated "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-09 17:22 +0100
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-09 13:31 -0300
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-09 13:31 -0300
Re: Javascript Object Extensions Updated "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-09 22:35 +0100
Re: Javascript Object Extensions Updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-09 21:49 +0000
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-09 19:06 -0300
Re: Javascript Object Extensions Updated "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-09 23:21 +0100
Re: Javascript Object Extensions Updated Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-01-10 01:38 +0000
Re: Javascript Object Extensions Updated "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-10 11:26 +0100
Re: Javascript Object Extensions Updated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-10 13:32 +0100
Re: Javascript Object Extensions Updated "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2016-01-10 20:04 +0100
Re: Javascript Object Extensions Updated Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2016-01-10 20:39 +0100
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-10 17:09 -0300
Re: Javascript Object Extensions Updated Simon Blackwell <syblackwell@anywhichway.com> - 2016-01-09 14:01 -0800
Re: Javascript Object Extensions Updated "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2016-01-09 16:19 -0800
Re: Javascript Object Extensions Updated Aleksandro <aleksandro@gmx.com> - 2016-01-09 21:49 -0300
Page 2 of 2 — ← Prev page 1 [2]
| From | Aleksandro <aleksandro@gmx.com> |
|---|---|
| Date | 2016-01-10 17:09 -0300 |
| Message-ID | <n6udkh$24j$1@dont-email.me> |
| In reply to | #29217 |
On 10/01/16 16:39, Thomas 'PointedEars' Lahn wrote: > If the latter, then we are finally back on topic: > > Above said, the author of the sentence committed a fallacy in the first > place by assuming that the referred blog post was intended to be a > documentation. Trolly, you should try to actually read the threads, really... On 09/01/16 11:12, Simon Blackwell wrote: > ...Note, there are risks in using polyfills as documented here: http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/...
[toc] | [prev] | [next] | [standalone]
| From | Simon Blackwell <syblackwell@anywhichway.com> |
|---|---|
| Date | 2016-01-09 14:01 -0800 |
| Message-ID | <a3648e95-05e9-47d5-bf8b-a67bde747713@googlegroups.com> |
| In reply to | #29183 |
On Saturday, January 9, 2016 at 10:27:14 AM UTC-5, Aleksandro wrote: > On 09/01/16 11:12, Simon Blackwell wrote: > > On Saturday, January 9, 2016 at 8:55:26 AM UTC-5, Simon Blackwell wrote: > >> On Thursday, January 7, 2016 at 5:45:18 PM UTC-5, Michael Haufe (TNO) wrote: > >>> On Thursday, January 7, 2016 at 4:29:25 PM UTC-6, Simon Blackwell wrote: > >>>> Javascript Object Extensions is a browser and Node.js library that adds missing and convenience functions and properties to Number, String, Boolean, Date, Array and Set. > >>>> > >>>> It adds lt, lte, eq, neq, gte, gt to Number, String, Boolean, Date. Dates can be compared with precision, e.g. *.lt(date,"Y")*. > >>>> > >>>> Between and outside are added to Number and String. > >>>> > >>>> For language processing apps the useful functions soundex and echoes are added to String. > >>>> > >>>> The methods isLeapYear and getLastDayOfMonth are added to Date as well as properties for year, fullYear, month, etc. Joex also adds data members to represent all of the parts of a Date so that they can be treated in a declarative manner. > >>>> > >>>> Intersection, intersects, disjoint, coincident, crossproduct, min, max, avg are added to to Array and Set. And, some, every, and toJSON are added to Set. toJSON results in an array like representation. > >>>> > >>>> Available at https://github.com/anywhichway/joex/ and via https://www.npmjs.com/package/joex > >>> > >>> "The disadvantages of Javascript polyfills": > >>> <http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/> > >> > >> I can only presume this is an objection to this library since there were no comments. I am fully aware of the danger of polyfills and will update the README of the libary to point to the referenced article. That being said, I hold there are cases where polyfills may be the only choice, i.e. where instanceof semantics must be preserved or major portions of existing code will have to be re-written (introducing yet another set of risks). This library was designed in such a way that the programmer has the ability to select which polyfills to use and can take the risks in an informed manner. > > > > The README has been uodated to say: > > > > "Note, there are risks in using polyfills as documented here: http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/. However, we have found there are cases where facades and wrappers will not work, making polyfills or subclassing the only choice, i.e. where instanceof semantics must be preserved or major portions of existing code will have to be re-written (introducing yet another set of risks). We attempted to develop the library using subclassing; however, the Chrome engine does some internal checking on instances before method invocation and we were getting errors related to generic function calls and instances not being of the correct type. We will continue to endeavor to enhance this library so that it does not compel the use of a polyfill so that all choice is in the end developer's hands. Meanwhile, the library was designed in such a way that the programmer has the ability to select which polyfills to use and can take the risks in an informed manner." > > I'd say that blog post lacks way too many examples, use cases and > serious studies to be called anything close to documentation. > That's more in the line of: > X is not perfect so Y, which I personally like, must be used always. > Proof: > X fails in one example. Happy to include a different link in the README. Just did not want others with similar concerns to ignore the joex library thinking we had not thought of the concerns. The blog post does bring up reasonable issues, even if it is not complete.
[toc] | [prev] | [next] | [standalone]
| From | "Michael Haufe (TNO)" <tno@thenewobjective.com> |
|---|---|
| Date | 2016-01-09 16:19 -0800 |
| Message-ID | <13b9d98d-dd83-4734-b3e3-0c5b599e3663@googlegroups.com> |
| In reply to | #29193 |
On Saturday, January 9, 2016 at 4:01:29 PM UTC-6, Simon Blackwell wrote: > Happy to include a different link in the README. Just did not want others with similar concerns to ignore the joex library thinking we had not thought of the concerns. The blog post does bring up reasonable issues, even if it is not complete. The willingness alone places it above a vast majority of libs...
[toc] | [prev] | [next] | [standalone]
| From | Aleksandro <aleksandro@gmx.com> |
|---|---|
| Date | 2016-01-09 21:49 -0300 |
| Message-ID | <n6s9la$5v7$1@dont-email.me> |
| In reply to | #29193 |
On 09/01/16 19:01, Simon Blackwell wrote: > On Saturday, January 9, 2016 at 10:27:14 AM UTC-5, Aleksandro wrote: >> On 09/01/16 11:12, Simon Blackwell wrote: >>> On Saturday, January 9, 2016 at 8:55:26 AM UTC-5, Simon Blackwell wrote: >>>> On Thursday, January 7, 2016 at 5:45:18 PM UTC-5, Michael Haufe (TNO) wrote: >>>>> On Thursday, January 7, 2016 at 4:29:25 PM UTC-6, Simon Blackwell wrote: >>>>>> Javascript Object Extensions is a browser and Node.js library that adds missing and convenience functions and properties to Number, String, Boolean, Date, Array and Set. >>>>>> >>>>>> It adds lt, lte, eq, neq, gte, gt to Number, String, Boolean, Date. Dates can be compared with precision, e.g. *.lt(date,"Y")*. >>>>>> >>>>>> Between and outside are added to Number and String. >>>>>> >>>>>> For language processing apps the useful functions soundex and echoes are added to String. >>>>>> >>>>>> The methods isLeapYear and getLastDayOfMonth are added to Date as well as properties for year, fullYear, month, etc. Joex also adds data members to represent all of the parts of a Date so that they can be treated in a declarative manner. >>>>>> >>>>>> Intersection, intersects, disjoint, coincident, crossproduct, min, max, avg are added to to Array and Set. And, some, every, and toJSON are added to Set. toJSON results in an array like representation. >>>>>> >>>>>> Available at https://github.com/anywhichway/joex/ and via https://www.npmjs.com/package/joex >>>>> >>>>> "The disadvantages of Javascript polyfills": >>>>> <http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/> >>>> >>>> I can only presume this is an objection to this library since there were no comments. I am fully aware of the danger of polyfills and will update the README of the libary to point to the referenced article. That being said, I hold there are cases where polyfills may be the only choice, i.e. where instanceof semantics must be preserved or major portions of existing code will have to be re-written (introducing yet another set of risks). This library was designed in such a way that the programmer has the ability to select which polyfills to use and can take the risks in an informed manner. >>> >>> The README has been uodated to say: >>> >>> "Note, there are risks in using polyfills as documented here: http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/. However, we have found there are cases where facades and wrappers will not work, making polyfills or subclassing the only choice, i.e. where instanceof semantics must be preserved or major portions of existing code will have to be re-written (introducing yet another set of risks). We attempted to develop the library using subclassing; however, the Chrome engine does some internal checking on instances before method invocation and we were getting errors related to generic function calls and instances not being of the correct type. We will continue to endeavor to enhance this library so that it does not compel the use of a polyfill so that all choice is in the end developer's hands. Meanwhile, the library was designed in such a way that the programmer has the ability to select which polyfills to use and can take the risks in an informed manner." >> >> I'd say that blog post lacks way too many examples, use cases and >> serious studies to be called anything close to documentation. >> That's more in the line of: >> X is not perfect so Y, which I personally like, must be used always. >> Proof: >> X fails in one example. > > Happy to include a different link in the README. Just did not want others with similar concerns to ignore the joex library thinking we had not thought of the concerns. The blog post does bring up reasonable issues, even if it is not complete. Personally I'd simply mention that some think that doing that is not appropriate. because it's just like that.
[toc] | [prev] | [standalone]
Page 2 of 2 — ← Prev page 1 [2]
Back to top | Article view | comp.lang.javascript
csiph-web