Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #29170 > unrolled thread

Javascript Object Extensions Updated

Back to article view | Back to comp.lang.javascript

Contents

  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 1 of 2  [1] 2  Next page →

#29170 — Javascript Object Extensions Updated

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

[toc] | [next] | [standalone]

#29171

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/>

[toc] | [prev] | [next] | [standalone]

#29172

On 07/01/16 19:45, 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 stopped reading when I saw Thomas Lahn in the list of “experts”.

[toc] | [prev] | [next] | [standalone]

#29173

On 7 January 2016 22:37:33 UTC-2, Aleksandro  wrote:
> On 07/01/16 19:45, Michael Haufe (TNO) wrote:

> > 
> > "The disadvantages of Javascript polyfills":
> > <http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/>
> 
> I stopped reading when I saw Thomas Lahn in the list of "experts".

This Adam Silver cannot be serious. For a moment, I thought I was reading Adam Sandler.

--
Joao Rodrigues

[toc] | [prev] | [next] | [standalone]

#29175

On Thursday, January 7, 2016 at 6:37:33 PM UTC-6, Aleksandro wrote:
> On 07/01/16 19:45, Michael Haufe (TNO) wrote:

> > "The disadvantages of Javascript polyfills":
> > <http://adamsilver.io/articles/the-disadvantages-of-javascript-polyfills/>
> 
> I stopped reading when I saw Thomas Lahn in the list of "experts".

I understand. The article has a bit of a learning curve once you decide to scroll the page.

[toc] | [prev] | [next] | [standalone]

#29179

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.

[toc] | [prev] | [next] | [standalone]

#29180

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

[toc] | [prev] | [next] | [standalone]

#29183

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.

[toc] | [prev] | [next] | [standalone]

#29184

Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in comp.lang.javascript:

> I'd say that blog post lacks way too many examples
[..] to be called anything close to documentation

How can something "lack too many"?

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29185

On 09/01/16 13:22, Evertjan. wrote:
> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in comp.lang.javascript:
> 
>> I'd say that blog post lacks way too many examples
> [..] to be called anything close to documentation
> 
> How can something "lack too many"?

Too mary more are needed, makes sense? :P

[toc] | [prev] | [next] | [standalone]

#29186

On 09/01/16 13:22, Evertjan. wrote:
> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in comp.lang.javascript:
> 
>> I'd say that blog post lacks way too many examples
> [..] to be called anything close to documentation
> 
> How can something "lack too many"?

Too many more are needed, makes sense?

[toc] | [prev] | [next] | [standalone]

#29191

Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
comp.lang.javascript: 

> On 09/01/16 13:22, Evertjan. wrote:
>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>> 
>>> I'd say that blog post lacks way too many examples
>> [..] to be called anything close to documentation
>> 
>> How can something "lack too many"?
> 
> Too many more are needed, makes sense?

No.

Would you perhaps mean "never enough"?


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29192

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
> comp.lang.javascript: 
>
>> On 09/01/16 13:22, Evertjan. wrote:
>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>>> 
>>>> I'd say that blog post lacks way too many examples
>>> [..] to be called anything close to documentation
>>> 
>>> How can something "lack too many"?
>> 
>> Too many more are needed, makes sense?
>
> No.
>
> Would you perhaps mean "never enough"?

Aleksandro phrase looks fine to me.  It's informal and colloquial
English but idiomatic and clear (to me of course -- obviously not to
all).  It's quite a common turn of phrase.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29194

On 09/01/16 18:49, Ben Bacarisse wrote:
> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> 
>> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
>> comp.lang.javascript: 
>>
>>> On 09/01/16 13:22, Evertjan. wrote:
>>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>>>>
>>>>> I'd say that blog post lacks way too many examples
>>>> [..] to be called anything close to documentation
>>>>
>>>> How can something "lack too many"?
>>>
>>> Too many more are needed, makes sense?
>>
>> No.
>>
>> Would you perhaps mean "never enough"?

I agree with that one but I did not mean that. :P

> Aleksandro phrase looks fine to me.  It's informal and colloquial
> English but idiomatic and clear (to me of course -- obviously not to
> all).  It's quite a common turn of phrase.

Actually I think I messed up a bit though, I am not a native English
speaker.

Anyway what I mean is that it lacks way too much proper examples. Or it
simply does.

[toc] | [prev] | [next] | [standalone]

#29195

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 09 Jan 2016 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> 
>> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
>> comp.lang.javascript: 
>>
>>> On 09/01/16 13:22, Evertjan. wrote:
>>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>>>> 
>>>>> I'd say that blog post lacks way too many examples
>>>> [..] to be called anything close to documentation
>>>> 
>>>> How can something "lack too many"?
>>> 
>>> Too many more are needed, makes sense?
>>
>> No.
>>
>> Would you perhaps mean "never enough"?
> 
> Aleksandro phrase looks fine to me.  It's informal and colloquial
> English but idiomatic and clear (to me of course -- obviously not to
> all).  It's quite a common turn of phrase.

So "lack too many" means "never enough"?

Ofcourse I can guess what Alexandro means,
but playing the devils advocate: 
what is so clear about it?

I don't like this guessing in a conversation,
I prefer asking.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29200

"Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 09 Jan 2016 in 
> comp.lang.javascript:
>
>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> 
>>> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
>>> comp.lang.javascript: 
>>>
>>>> On 09/01/16 13:22, Evertjan. wrote:
>>>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>>>>> 
>>>>>> I'd say that blog post lacks way too many examples
>>>>> [..] to be called anything close to documentation
>>>>> 
>>>>> How can something "lack too many"?
>>>> 
>>>> Too many more are needed, makes sense?
>>>
>>> No.
>>>
>>> Would you perhaps mean "never enough"?
>> 
>> Aleksandro phrase looks fine to me.  It's informal and colloquial
>> English but idiomatic and clear (to me of course -- obviously not to
>> all).  It's quite a common turn of phrase.
>
> So "lack too many" means "never enough"?

No, not to me.  I can't put it into the sentence and get anything that
makes the same sense to me.  The closest I can get is "that blog post
never has enough examples...", but "never" needs a plurality or range,
more like "those blog posts never have enough examples..." or maybe, at
a pinch, "that post, from start to finish, never has enough
examples...".

> Ofcourse I can guess what Alexandro means,
> but playing the devils advocate: 
> what is so clear about it?

I don't know.  I know it is clear (to me) but not what makes it so.  I
am not a linguist.

> I don't like this guessing in a conversation,
> I prefer asking.

Absolutely.  Best to ask if you are unsure.  I'm just adding a data
point -- for at least one native speaker, the meaning was clear.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#29204

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 10 Jan 2016 in 
comp.lang.javascript:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
> 
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 09 Jan 2016 in 
>> comp.lang.javascript:
>>
>>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>>> 
>>>> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
>>>> comp.lang.javascript: 
>>>>
>>>>> On 09/01/16 13:22, Evertjan. wrote:
>>>>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript: 
>>>>>> 
>>>>>>> I'd say that blog post lacks way too many examples
>>>>>> [..] to be called anything close to documentation
>>>>>> 
>>>>>> How can something "lack too many"?
>>>>> 
>>>>> Too many more are needed, makes sense?
>>>>
>>>> No.
>>>>
>>>> Would you perhaps mean "never enough"?
>>> 
>>> Aleksandro phrase looks fine to me.  It's informal and colloquial
>>> English but idiomatic and clear (to me of course -- obviously not to
>>> all).  It's quite a common turn of phrase.
>>
>> So "lack too many" means "never enough"?
> 
> No, not to me.  I can't put it into the sentence and get anything that
> makes the same sense to me.  The closest I can get is "that blog post
> never has enough examples...", but "never" needs a plurality or range,
> more like "those blog posts never have enough examples..." or maybe, at
> a pinch, "that post, from start to finish, never has enough
> examples...".

That was what I was asking, "never enough".

Even so "lack too many" is not a construction I would expect even for that.


> 
>> Ofcourse I can guess what Alexandro means,
>> but playing the devils advocate: 
>> what is so clear about it?
> 
> I don't know.  I know it is clear (to me) but not what makes it so.  I
> am not a linguist.
> 
>> I don't like this guessing in a conversation,
>> I prefer asking.
> 
> Absolutely.  Best to ask if you are unsure.  I'm just adding a data
> point -- for at least one native speaker, the meaning was clear.

I used to be a native speaker, long ago.

Eh, this sounds strange to me too, can one lose such nativity?

Is such nativity proof of language skill, 
or is the word native naively used here 
for primary language or primary local dialect perhaps?

Let's concentrate on the somewhat better defined languages like Javascript.


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29207

Ben Bacarisse wrote:

> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>> Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 09 Jan 2016 in
>> comp.lang.javascript:
>>> "Evertjan." <exxjxw.hannivoort@inter.nl.net> writes:
>>>> Aleksandro <aleksandro@gmx.com> wrote on 09 Jan 2016 in
>>>> comp.lang.javascript:
>>>>> On 09/01/16 13:22, Evertjan. wrote:
>>>>>> Aleksandro wrote on 09 Jan 2016 in comp.lang.javascript:

Attribution _line_, *not* attribution novel.  This could have been much 
better readable:

> "Evertjan." wrote:
>> Ben Bacarisse wrote:
>>> "Evertjan." wrote:
>>>> Aleksandro wrote:
>>>>> Evertjan. wrote:
>>>>>> Aleksandro wrote:

>>>>>>> I'd say that blog post lacks way too many examples
>>>>>> [..] to be called anything close to documentation
>> Ofcourse I can guess what Alexandro means,
>> but playing the devils advocate:
>> what is so clear about it?
> 
> I don't know.  I know it is clear (to me) but not what makes it so.  I
> am not a linguist.

In order to bring this off-topic thread¹ to a speedy conclusion: I am not a 
linguist either, but having studied the structure of languages (I am writing 
a translator software in my free time), I know more about them than the 
average user.

I am not a native speaker of English, but fluent in it.  And to me there
is no mystery what this statement means.  It can be broken down as follows:

lacks examples              = “examples are missing from it”
                              (i.e., examples are not there that should have
                              been there)

lacks many examples         = “a great number of examples is missing from
                               it”

lacks too many examples     = “a great number of examples that is too great
                               is missing from it”

lacks way too many examples = “a great number of examples that is much too
                               great [colloq. emphasis] is missing from it”

HTH

___________
¹  this is to be discussed in, e.g., <news:alt.english.usage> instead
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#29216

Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 10 Jan 2016 in
comp.lang.javascript: 

> lacks too many examples
> = a great number of examples that is too great is missing from it

It might be a syntactically correct interpretation, 
and I do not think it is, 
but even if it were, 
the sentence is utter nonsense.

a comparable example of such correct syntax:

"This delicious salad is missing to many car-parts, kisses,
twenty-three ancient monuments and a miriad of celestrial objects,
so it does not fail to have sexual intercourse before its time."


-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#29217

Evertjan. wrote:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> wrote on 10 Jan 2016 in
> comp.lang.javascript:

Again, it is called an attribution _line_, *not* an attribution novel.

The e-mail address is irrelevant; the proper contact address is in the 
“Reply-To” header field in this case.

The date is irrelevant; the statements made are relevant no matter when they 
were made, and if there is doubt, one can look into the “Date” header field 
of the precursor.  If that is not available on the same news server, it is 
available in newsgroup archives.

The newsgroup is already in the “Newsgroups” header field value of the 
precursor; and since there was no crosspost here, it is the same newsgroup 
as in your posting.

So *all* of this is *superfluous* information in your postings.  Why do you 
not simply omit it, and make your postings, and threads in which you 
participate, easier readable?

And stop the address munging.

When will you *ever* learn?

>> lacks too many examples
>> = a great number of examples that is too great is missing from it
> 
> It might be a syntactically correct interpretation,

That is a _semantic_ interpretation, and it is correct.  “Syntactically 
correct” means something else.

> and I do not think it is,

Saying so does not make it so.

> but even if it were, the sentence is utter nonsense.

“Utter nonsense” in that it has no discernible meaning for you, or in that 
you do not agree with the statement?


If the former, it means, if the “lacks way too many” is resolved, that, in 
the opinion of the author of the sentence, there are too few examples in the 
blog post (for a documentation).

As a non-native speaker of English whose record shows that they are 
challenged with properly understanding even the simplest of English words 
and sentences, you should be slow to pass judgement as to the correctness of 
(my) interpretations, and the sense, of sentences in English – particularly 
when colloquial speech has been used.


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.

And *host* objects should not be augmented indeed.  For good reasons that 
can be found in the newsgroup archive.  After intense discussion, that has 
become consensus here since more than a decade (all of the people listed as 
“experts” in the blog post have been or still are regular contributors to 
this newsgroup).  I would seem that the jQuery people, among others, had to 
learn it the hard way again; they are no longer augmenting host objects, but 
keep a registry for element augmentation.
 
-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | SVN: <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | ES Matrix: <http://PointedEars.de/es-matrix>
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.javascript

csiph-web