Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.javascript > #16703 > unrolled thread
| Started by | Patricia Shanahan <pats@acm.org> |
|---|---|
| First post | 2012-10-18 08:32 +0100 |
| Last post | 2012-10-21 17:57 -0700 |
| Articles | 20 on this page of 113 — 20 participants |
Back to article view | Back to comp.lang.javascript
Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 08:32 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-18 10:23 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:42 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-18 17:59 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-18 09:56 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-19 00:49 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-19 11:04 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 11:52 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-19 12:06 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-19 23:12 +0100
Re: Programming style question "Mel Smith" <med_cutout_syntel@aol.com> - 2012-10-19 21:56 -0600
Re: Programming style question Bart Van der Donck <bart@nijlen.com> - 2012-10-20 02:21 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 12:03 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-20 06:31 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 18:30 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-20 10:32 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-20 22:34 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-21 10:12 +0200
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-21 09:34 +0100
Re: Programming style question Dr J R Stockton <reply1242@merlyn.demon.co.uk.invalid> - 2012-10-21 17:59 +0100
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-22 09:55 +0200
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-22 09:50 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-22 04:49 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-22 14:04 +0100
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-22 16:07 +0200
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-23 18:22 +0100
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-22 16:01 +0200
Re: Programming style question Jim T. <x@y.z> - 2012-10-22 12:16 -0400
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-22 11:40 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-22 14:01 -0700
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:07 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-23 09:43 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-23 11:49 +0200
Re: Programming style question Jim T. <x@y.z> - 2012-10-23 15:52 -0400
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-23 13:07 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-23 22:45 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-23 14:14 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-24 09:35 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-24 10:17 -0700
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-25 18:41 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-25 17:03 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-25 20:14 -0700
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-25 20:46 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-26 09:55 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-26 06:18 -0700
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-26 17:43 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-26 09:57 -0700
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-26 10:24 -0700
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-26 14:18 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 10:45 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 12:58 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 16:18 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 18:08 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 18:26 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 19:43 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-27 21:09 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-27 22:53 +0200
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-28 11:37 +0000
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 12:50 +0100
Re: Programming style question Martin Leese <please@see.Web.for.e-mail.INVALID> - 2012-10-28 13:43 -0600
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-28 23:58 +0100
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-29 11:18 +0000
Re: Programming style question Eric Bednarz <bednarz@fahr-zur-hoelle.org> - 2012-10-27 23:58 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-28 12:43 +0100
Re: Programming style question Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> - 2012-10-27 19:44 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-24 12:06 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 21:27 +0200
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-10-24 15:12 -0700
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-10-25 01:29 +0100
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-24 21:25 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 21:57 +0200
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-25 01:11 +0200
Re: Programming style question Christoph Becker <cmbecker69@gmx.de> - 2012-10-25 02:00 +0200
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-24 20:27 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 08:44 +0200
Re: Programming style question Adam Silver <adambsilver@gmail.com> - 2012-10-25 04:28 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-25 23:18 +0200
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-26 08:24 -0700
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-11-07 22:13 +0100
Re: Programming style question Tim Streater <timstreater@greenbee.net> - 2012-11-07 21:51 +0000
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-11-07 23:47 +0100
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-11-08 01:14 +0100
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-11-07 16:51 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 16:45 +0100
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-11-08 08:02 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 17:39 +0100
Re: Programming style question Gene Wirchenko <genew@ocis.net> - 2012-11-08 11:25 -0800
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-08 22:25 +0100
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-11-09 10:19 +0000
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-11-09 17:41 +0100
Re: Programming style question Dr J R Stockton <reply1245@merlyn.demon.co.uk.invalid> - 2012-11-10 22:38 +0000
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-22 12:32 -0700
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:05 +0200
Re: Programming style question Christoph Becker <cmbecker69@gmx.de> - 2012-10-22 22:11 +0200
Re: Programming style question Stefan Weiss <krewecherl@gmail.com> - 2012-10-23 02:42 +0200
Re: Programming style question Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-10-23 10:08 +0200
Re: Programming style question "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2012-10-20 18:34 +0200
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-18 11:57 +0200
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:06 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-18 15:32 +0300
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 13:37 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-18 15:55 +0300
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-19 10:12 +0100
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-19 07:24 -0700
Re: Programming style question John G Harris <john@nospam.demon.co.uk> - 2012-10-20 17:47 +0100
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:15 +0100
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:31 +0100
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-24 07:34 +0300
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 19:57 +0200
Re: Programming style question "Jukka K. Korpela" <jkorpela@cs.tut.fi> - 2012-10-24 21:02 +0300
Re: Programming style question Patricia Shanahan <pats@acm.org> - 2012-10-18 20:15 -0700
Re: Programming style question Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-10-24 01:21 +0100
Re: Programming style question Scott Sauyet <scott.sauyet@gmail.com> - 2012-10-21 17:57 -0700
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | "Evertjan." <exxjxw.hannivoort@inter.nl.net> |
|---|---|
| Date | 2012-10-28 23:58 +0100 |
| Message-ID | <XnsA0FAF3E32F3A8eejj99@194.109.133.133> |
| In reply to | #16934 |
Martin Leese wrote on 28 okt 2012 in comp.lang.javascript: > Thomas 'PointedEars' Lahn wrote: > ... >> Last time I checked, `&' was _not_ a letter, and `&&' was _not_ a >> "complete word". > > Ampersands are used in normal (not code) > text all the time. Therefore, Google treats > them as a letter. This is simply fortuitous, > and does not indicate Google's general > policy towards non-letters. The same goes for @. The same goes for #, well not quite, while the & can appear in a word, # is indexed only as a first letter. Now try the @, #, &, !, +, - and indeed the | as a single letter, and, while they are not indexed as such, they are "translated" by Google search to their textual English[!!] equivalent, like "vertical bar", "plus sign", "minus"/"hyphen", etc. The ways of Google are inscrutinable, diverse and even inconstant in time. -- Evertjan. The Netherlands. (Please change the x'es to dots in my emailaddress)
[toc] | [prev] | [next] | [standalone]
| From | John G Harris <john@nospam.demon.co.uk> |
|---|---|
| Date | 2012-10-29 11:18 +0000 |
| Message-ID | <r52zV4DHYmjQFwF5@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD> |
| In reply to | #16920 |
On Sun, 28 Oct 2012 at 12:50:39, in comp.lang.javascript, Thomas 'PointedEars' Lahn wrote: <snip> >I did not debate that; in fact, I am confirming above that `||' and `"||"' >do not yield results. You, too, want to learn to read. <snip> No, it's you who needs to learn to read. I did not say or imply that you had denied it, though I'm not sure that your guess was correct. I merely added some facts to this discussion. John -- John Harris
[toc] | [prev] | [next] | [standalone]
| From | Eric Bednarz <bednarz@fahr-zur-hoelle.org> |
|---|---|
| Date | 2012-10-27 23:58 +0200 |
| Message-ID | <m2k3ubtw4s.fsf@nntp.bednarz.nl> |
| In reply to | #16883 |
Gene Wirchenko <genew@ocis.net> writes: > Try Googling for "||". No results! I'd rather not get involved with the rest of this threat (or thread), but on a newsgroup about programming, you really oughta now how to search for code (and stuff). http://code.google.com/codesearch#search/&q=%5C%7C%5C%7C%20lang:%5Ejavascript$&type=cs
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-28 12:43 +0100 |
| Message-ID | <1472788.XcsFiRXOVZ@PointedEars.de> |
| In reply to | #16915 |
Eric Bednarz wrote: > Gene Wirchenko <genew@ocis.net> writes: >> Try Googling for "||". No results! > > I'd rather not get involved with the rest of this threat (or thread), but > on a newsgroup about programming, you really oughta now how to search for > code (and stuff). > > http://code.google.com/codesearch#search/&q=%5C%7C%5C%7C%20lang > %5Ejavascript$&type=cs It should be noted that it only searches in developers.google.com and code.google.com. PointedEars -- Danny Goodman's books are out of date and teach practices that are positively harmful for cross-browser scripting. -- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | Dr J R Stockton <reply1243@merlyn.demon.co.uk.invalid> |
|---|---|
| Date | 2012-10-27 19:44 +0100 |
| Message-ID | <tdpDPZIOuCjQFwHA@invalid.uk.co.demon.merlyn.invalid> |
| In reply to | #16883 |
In comp.lang.javascript message <luvj88ldgtr18fqdr2330b4msbgmd91nf9@4ax. com>, Thu, 25 Oct 2012 20:14:48, Gene Wirchenko <genew@ocis.net> posted: >On Thu, 25 Oct 2012 17:03:19 -0700, Patricia Shanahan <pats@acm.org> >wrote: > >>On 10/25/2012 10:41 AM, Dr J R Stockton wrote: >>> In comp.lang.javascript message <bh7g885ekk9ce55mmqec0bo2k12605ak6l@4ax. >>> com>, Wed, 24 Oct 2012 10:17:13, Gene Wirchenko <genew@ocis.net> posted: >>> >>>> >>>> Some of these idioms are showstoppers, because how do you look >>>> something up if you do not know its name and it is mainly an >>>> arrangement of symbols? >>> >>> You look it up in the index of a book, where the symbols should come >>> before the words. Four of my five JavaScript books are like that, one >>> having numbers before symbols. The fifth, and most used, has no index. > > I was more concerned with the idiom. If one does not know the >name, it is hard to look it up. If you find the index entry, the name should be beside it; and the page indicated by number should tell you more. Wikipedia has a "vertical bar" page, which includes "whilst a double vertical bar (a || b) denotes a _(short-circuited)_ _logical or_.". Google knows a lot about '"double vertical bar"' and '"double vertical bar" JavaScript'; some of it will be right. -- (c) John Stockton, nr London UK Reply address via Home Page. news:comp.lang.javascript FAQ <http://www.jibbering.com/faq/index.html>. <http://www.merlyn.demon.co.uk/js-index.htm> jscr maths, dates, sources. <http://www.merlyn.demon.co.uk/> TP/BP/Delphi/jscr/&c, FAQ items, links.
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-24 12:06 -0700 |
| Message-ID | <H8Cdnb-fM7uqoRXNnZ2dnUVZ_gydnZ2d@earthlink.com> |
| In reply to | #16831 |
On 10/24/2012 12:35 AM, Evertjan. wrote:
...
> Well, you are looking the wrong way, it seems,
> these oprators, especially || are regulary used
> in Javascript to prevent errors when a function is not available
> on a platform, so at runtime, when you as a programmer are not available.
>
> var r = aDOMfunction || aDOMfunction("23px");
I've looked at this several times, and think it should be "&&" not "||".
"||" evaluates the right hand side if the left hand side is not truthy,
in this case if the function does not exist.
Surely one wants to evaluate the right hand side if, and only if,
aDOMfunction *does* exist. That is what "&&" would do.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 21:27 +0200 |
| Message-ID | <6590377.0brVofrJPU@PointedEars.de> |
| In reply to | #16835 |
Patricia Shanahan wrote:
> On 10/24/2012 12:35 AM, Evertjan. wrote:
>> Well, you are looking the wrong way, it seems,
>> these oprators, especially || are regulary used
>> in Javascript to prevent errors when a function is not available
>> on a platform, so at runtime, when you as a programmer are not available.
>>
>> var r = aDOMfunction || aDOMfunction("23px");
>
> I've looked at this several times, and think it should be "&&" not "||".
>
> "||" evaluates the right hand side if the left hand side is not truthy,
> in this case if the function does not exist.
>
> Surely one wants to evaluate the right hand side if, and only if,
> aDOMfunction *does* exist. That is what "&&" would do.
Correct. It is insufficient and error-prone a feature test, though: A true-
value does not need to be callable, and a host object can throw an exception
on type conversion or even non-calling read access. Search for
implementations of `isNativeMethod' and `isHostMethod' instead (you can find
one in JSX:object.js).
`||' is useful for implementing default values, but slightly overkill for
default parameter values (unless they are not used left-hand side of the
assignment).
PointedEars
--
realism: HTML 4.01 Strict
evangelism: XHTML 1.0 Strict
madness: XHTML 1.1 as application/xhtml+xml
-- Bjoern Hoehrmann
[toc] | [prev] | [next] | [standalone]
| From | Gene Wirchenko <genew@ocis.net> |
|---|---|
| Date | 2012-10-24 15:12 -0700 |
| Message-ID | <sqpg889bkb0cthn44viic8ku6onkj2liak@4ax.com> |
| In reply to | #16835 |
On Wed, 24 Oct 2012 12:06:56 -0700, Patricia Shanahan <pats@acm.org>
wrote:
>On 10/24/2012 12:35 AM, Evertjan. wrote:
>...
>> Well, you are looking the wrong way, it seems,
>> these oprators, especially || are regulary used
>> in Javascript to prevent errors when a function is not available
>> on a platform, so at runtime, when you as a programmer are not available.
>>
>> var r = aDOMfunction || aDOMfunction("23px");
>
>I've looked at this several times, and think it should be "&&" not "||".
|| did not make sense to me either.
>"||" evaluates the right hand side if the left hand side is not truthy,
>in this case if the function does not exist.
>
>Surely one wants to evaluate the right hand side if, and only if,
>aDOMfunction *does* exist. That is what "&&" would do.
If so, then that makes two errors in Evertjan's post -- see my
other post for the other with || and alert(). That is not a good
argument for tricky coding.
Sincerely,
Gene Wirchenko
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-10-25 01:29 +0100 |
| Message-ID | <timstreater-75F6C9.01290425102012@news.individual.net> |
| In reply to | #16835 |
In article <H8Cdnb-fM7uqoRXNnZ2dnUVZ_gydnZ2d@earthlink.com>,
Patricia Shanahan <pats@acm.org> wrote:
> On 10/24/2012 12:35 AM, Evertjan. wrote:
> ...
> > Well, you are looking the wrong way, it seems,
> > these oprators, especially || are regulary used
> > in Javascript to prevent errors when a function is not available
> > on a platform, so at runtime, when you as a programmer are not available.
> >
> > var r = aDOMfunction || aDOMfunction("23px");
>
> I've looked at this several times, and think it should be "&&" not "||".
Mmmm. Illustrates my point about why I write these things somewhat more
verbosely.
--
Tim
"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
| From | Stefan Weiss <krewecherl@gmail.com> |
|---|---|
| Date | 2012-10-24 21:25 +0200 |
| Message-ID | <k69fb6$530$1@news.albasani.net> |
| In reply to | #16831 |
On 2012-10-24 09:35, Evertjan. wrote:
>>>Asking what OTHER languages have the same syntax as Javascript?
>>>
>>>This surely is off topic in this NG,
>>>as it does not even help understanding Javascript.
I strongly disagree with that statement. Comparing JavaScript to other
languages is very much on topic in this group. If you're not interested
in those discussions, feel free to skip them.
> var r = aDOMfunction || aDOMfunction("23px");
That's either a typo or complete nonsense. If the function aDOMfunction
exists, copy a reference to the r variable; if it doesn't exist, call it
anyway?
> alert( 'a!=3 is ' + !!( a==3 || alert('a is not 3') ) );
As Gene already noted, this is overly complicated and gives the wrong
result.
> Oh sorry, perhaps you don't like this
> BECAUSE you cannot do this in some other language,
> where you would desperately need multiline if-else-then constructs.
Just because you can write cryptic code in JS doesn't mean you have go
out of your way to do it.
Talking about cryptic code, the || operator in Perl works in a similar
way. There's even some syntactic sugar for assigning default values to
variables:
$foo = $foo || 42;
can be shortened to
$foo ||= 42;
But enough about other languages, I don't want to bore you with these
"off topic" comparisons. Here are some better examples for where the
value returned by the || operator can be used in JS:
// simple default values
var textColor = opts.color || userPrefs.color || "black";
// DOM0 event handler
document.onclick = function (evt) {
var e = evt || window.event;
...
};
// initialize a "namespace" object without overwriting it
var myLib = myLib || {};
myLib.myFunc = function () { ... };
// call a method on an optional argument
function findParagraphs (parentEle) {
return (parentEle || document).getElementsByTagName("p");
}
// combining && and ||
function textOfFirst (parentEle, eleName) {
var ele = parentEle.getElementsByTagName(eleName)[0];
return ele && ele.firstChild && ele.firstChild.data || "";
}
- stefan
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 21:57 +0200 |
| Message-ID | <3335047.320Uf1SXUN@PointedEars.de> |
| In reply to | #16836 |
Stefan Weiss wrote:
> On 2012-10-24 09:35, Evertjan. wrote:
>>>> Asking what OTHER languages have the same syntax as Javascript?
>>>>
>>>> This surely is off topic in this NG,
>>>> as it does not even help understanding Javascript.
>
> I strongly disagree with that statement. Comparing JavaScript to other
> languages is very much on topic in this group. If you're not interested
> in those discussions, feel free to skip them.
ACK.
>> Oh sorry, perhaps you don't like this
>> BECAUSE you cannot do this in some other language,
>> where you would desperately need multiline if-else-then constructs.
>
> Just because you can write cryptic code in JS doesn't mean you have go
> out of your way to do it.
ACK.
> Talking about cryptic code, the || operator in Perl works in a similar
> way. There's even some syntactic sugar for assigning default values to
> variables:
> $foo = $foo || 42;
> can be shortened to
> $foo ||= 42;
There is also
$foo = 42 if not defined $foo;
and similar in Perl, which is probably slightly more efficient [no
assignment if $foo is not defined()/whatever].
> But enough about other languages, I don't want to bore you with these
> "off topic" comparisons. Here are some better examples for where the
> value returned by the || operator can be used in JS:
>
> // simple default values
> var textColor = opts.color || userPrefs.color || "black";
There is a real use-case for that.
> // DOM0 event handler
> document.onclick = function (evt) {
> var e = evt || window.event;
> ...
> };
This is error-prone if `evt' refers to a host object, and unnecessarily
inefficient. And document.onclick?
> // initialize a "namespace" object without overwriting it
> var myLib = myLib || {};
This is unnecessarily complicated. An `if' statement will do better and
will be slightly more efficient.
> myLib.myFunc = function () { ... };
>
> // call a method on an optional argument
> function findParagraphs (parentEle) {
> return (parentEle || document).getElementsByTagName("p");
> }
This can be error-prone. In particular, there is a problem when expression
in the `||' operation is a reference to a Function instance. Some functions
can only be called as methods of an (specific) object.
> // combining && and ||
> function textOfFirst (parentEle, eleName) {
> var ele = parentEle.getElementsByTagName(eleName)[0];
> return ele && ele.firstChild && ele.firstChild.data || "";
> }
This is error-prone as the return type would vary (one of Null, Element or
descendant, Text, or String) depending on runtime conditions that one has
virtually no control over. (In fact, the first line is error-prone already
as null has no properties). To be avoided.
PointedEars
--
Anyone who slaps a 'this page is best viewed with Browser X' label on
a Web page appears to be yearning for the bad old days, before the Web,
when you had very little chance of reading a document written on another
computer, another word processor, or another network. -- Tim Berners-Lee
[toc] | [prev] | [next] | [standalone]
| From | Stefan Weiss <krewecherl@gmail.com> |
|---|---|
| Date | 2012-10-25 01:11 +0200 |
| Message-ID | <k69sis$vc$1@news.albasani.net> |
| In reply to | #16838 |
I've been waiting for this... It seems that every time I post code to
this group, I get a reply filled with pedantic nitpicks and irrelevant
criticism from you. I do enjoy constructive feedback, but all this
disagreeing for the sake of disagreeing is a waste of everyone's time.
Especially when you intentionally misinterpret short code examples as
something they were never meant to be.
Anyway...
On 2012-10-24 21:57, Thomas 'PointedEars' Lahn wrote:
>> // DOM0 event handler
>> document.onclick = function (evt) {
>> var e = evt || window.event;
>> ...
>> };
>
> This is error-prone if `evt' refers to a host object, and unnecessarily
> inefficient. And document.onclick?
This is a simple example of one very common usage of the || operator,
not an endorsement of DOM0-style event handling, so yes, document.onclick.
As for error-prone, that's a huge exaggeration. It's true that the event
object is a host object, but this particular form of checking for an
event object as the first argument has been widely used without problems
since the mid 90s. Defensive programming is a good habit, but it can be
carried to far.
And "inefficient"? In a click handler? This statement will be evaluated
(at most) once every time the user clicks. I'm quite certain that any
difference in performance between this example and whatever you would
offer as an alternative cannot even be measured under these circumstances.
>> // initialize a "namespace" object without overwriting it
>> var myLib = myLib || {};
>
> This is unnecessarily complicated. An `if' statement will do better and
> will be slightly more efficient.
So you would prefer one of these?
if (!myLib) {
var myLib = {};
}
if (typeof myLib == "undefined") {
var myLib = {};
}
What I wrote looks less complicated to me, but in the end it's just a
matter of personal taste. As with the first example, the efficiency of
this statement is completely irrelevant in the typical case (i.e., at
the beginning of an included file). Your version may save a single
assignment, and only if myLib already exists. Why worry about such details?
>> myLib.myFunc = function () { ... };
>>
>> // call a method on an optional argument
>> function findParagraphs (parentEle) {
>> return (parentEle || document).getElementsByTagName("p");
>> }
>
> This can be error-prone. In particular, there is a problem when expression
> in the `||' operation is a reference to a Function instance. Some functions
> can only be called as methods of an (specific) object.
You're imagining things, my overly critical friend. As you can guess
from the code, this function is intended to be called with an element
node, or no arguments. Pass an unsupported argument and you will get an
error. If that's your definition of error-prone, you will need to check
each end every argument in every single function. Sure, that's possible,
but if you do that, stop complaining about inefficient code.
>> // combining && and ||
>> function textOfFirst (parentEle, eleName) {
>> var ele = parentEle.getElementsByTagName(eleName)[0];
>> return ele && ele.firstChild && ele.firstChild.data || "";
>> }
>
> This is error-prone as the return type would vary (one of Null, Element or
> descendant, Text, or String) depending on runtime conditions that one has
> virtually no control over. (In fact, the first line is error-prone already
> as null has no properties). To be avoided.
Please explain how this function can possibly return anything other than
a string (under non-pathological* circumstances).
Again, if you insist on passing unsupported arguments to a function, you
deserve what you get.
- stefan
*) The only way I can think of to create such an outcome would be to
augment the first child node of the first 'eleName' descendant of
'parentEle' with a custom non-string .data property, thereby shadowing
the DOM property (the .firstChild property cannot be shadowed, AFAIK).
That would be a very stupid thing to do, and I don't cater to stupidity.
YMMV. If you're writing a general purpose library for the unwashed
masses, you'll have to do more handholding.
[toc] | [prev] | [next] | [standalone]
| From | Christoph Becker <cmbecker69@gmx.de> |
|---|---|
| Date | 2012-10-25 02:00 +0200 |
| Message-ID | <k69ve4$nc6$1@speranza.aioe.org> |
| In reply to | #16846 |
Stefan Weiss wrote: > I've been waiting for this... It seems that every time I post code to > this group, I get a reply filled with pedantic nitpicks and irrelevant > criticism from you. I do enjoy constructive feedback, but all this > disagreeing for the sake of disagreeing is a waste of everyone's time. > Especially when you intentionally misinterpret short code examples as > something they were never meant to be. I wouldn't call Thomas' comments pedantic, but rather meticulous (I hope I understand the finer details of the English language here; in German it would be "pedantisch" vs. "akribisch"). And I assume, that Thomas' comments are not meant to demonstrate that his knowledge of ECMAScript is superior to others (what would IMHO be illogical), but merely to help to avoid mistakes that he (?) and others have already made. And, being a novice regarding web development, I quite appreciate this kind of support--one might not get that in other places for free. About your code samples: I've found them to be the most useful ones offered in this thread. Most others seemed to have the only purpose to show some wizardry that's possible--your's were quite practical uses of the || and && operators (even if they /might/ have some minor flaws). Thanks for conveying. -- Christoph M. Becker
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott.sauyet@gmail.com> |
|---|---|
| Date | 2012-10-24 20:27 -0700 |
| Message-ID | <4424b6d8-ad1f-40f1-9c53-76ce8d1e6edb@b12g2000vbg.googlegroups.com> |
| In reply to | #16847 |
Christoph Becker wrote: > Stefan Weiss wrote: >> I've been waiting for this... It seems that every time I post code to >> this group, I get a reply filled with pedantic nitpicks and irrelevant >> criticism from you. I do enjoy constructive feedback, but all this >> disagreeing for the sake of disagreeing is a waste of everyone's time. >> Especially when you intentionally misinterpret short code examples as >> something they were never meant to be. > > I wouldn't call Thomas' comments pedantic, Many others have, and with good cause, I believe. > but rather meticulous (I hope > I understand the finer details of the English language here; in German > it would be "pedantisch" vs. "akribisch"). I don't know German, so I can't comment on that, but many here have suggested that Thomas is often pedantic, and it's meant in all the senses as defined in Wiktionary [1] or Merriam-Webster [2] and not simply those that overlap with "meticulous". > And I assume, that Thomas' > comments are not meant to demonstrate that his knowledge of ECMAScript > is superior to others (what would IMHO be illogical), but merely to help > to avoid mistakes that he (?) and others have already made. And, being > a novice regarding web development, I quite appreciate this kind of > support--one might not get that in other places for free. Thomas' advice is frequently good, sometimes excellent. He is an extremely valuable contributor to this group. But he has more points on which he is prickly than pretty much anyone else around here. And his pedantic nature asserts itself quite often. > About your code samples: I've found them to be the most useful ones > offered in this thread. Most others seemed to have the only purpose to > show some wizardry that's possible--your's were quite practical uses of > the || and && operators (even if they /might/ have some minor flaws). Stefan is another of our most valuable contributors. He does not post nearly as often as Thomas, and he is less interested in some of the long-running debates that sometime consume others, but he does step in with excellent advice fairly often, and he manages to do so in a friendly, helpful manner. And IMHO, those samples have no flaws, not even minor ones. I have used something much like each and every one of these techniques many times with no adverse affects. This is not to say that Thomas won't be able to point to some obscure corner case where they would not work as expected, but I've yet to have such cases affect my day-to-day life as a developer. -- Scott [1] http://en.wiktionary.org/wiki/pedantic [2] http://www.merriam-webster.com/dictionary/pedant?show=0&t=1351134290
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-25 08:44 +0200 |
| Message-ID | <5017391.VPvXHtRtVa@PointedEars.de> |
| In reply to | #16846 |
Stefan Weiss wrote: > I've been waiting for this... It seems that every time I post code to > this group, I get a reply filled with pedantic nitpicks and irrelevant > criticism from you. I do enjoy constructive feedback, but all this > disagreeing for the sake of disagreeing is a waste of everyone's time. > Especially when you intentionally misinterpret short code examples as > something they were never meant to be. You may believe what you want. Do not expect it to be the truth, though. > […] I might comment on the rest later. Do not expect that lack of comment is indication that your arguments are sound, though. PointedEars -- Sometimes, what you learn is wrong. If those wrong ideas are close to the root of the knowledge tree you build on a particular subject, pruning the bad branches can sometimes cause the whole tree to collapse. -- Mike Duffy in cljs, <news:Xns9FB6521286DB8invalidcom@94.75.214.39>
[toc] | [prev] | [next] | [standalone]
| From | Adam Silver <adambsilver@gmail.com> |
|---|---|
| Date | 2012-10-25 04:28 -0700 |
| Message-ID | <3050faa6-aad7-497f-a592-0d0e37aeced8@googlegroups.com> |
| In reply to | #16850 |
On Thursday, October 25, 2012 7:44:15 AM UTC+1, Thomas 'PointedEars' Lahn wrote: > Stefan Weiss wrote: > > > > > [I've been waiting for this...] > > > > You may believe what you want. Do not expect it to be the truth, though. > > > > > […] > > > > I might comment on the rest later. Do not expect that lack of comment is > > indication that your arguments are sound, though. > > > > > > PointedEars The detail Thomas goes into and his 'nitpicks' are extremely helpful to me and others. Calling someone as helpful as Thomas a troll is certainly not helpful.
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-25 23:18 +0200 |
| Message-ID | <4756074.nmYHGREfxK@PointedEars.de> |
| In reply to | #16846 |
Stefan Weiss wrote:
> I've been waiting for this... It seems that every time I post code to
> this group, I get a reply filled with pedantic nitpicks and irrelevant
> criticism from you. I do enjoy constructive feedback, but all this
> disagreeing for the sake of disagreeing is a waste of everyone's time.
> Especially when you intentionally misinterpret short code examples as
> something they were never meant to be.
I did not want to comment on that nonsense anymore, but I am finding now
that it needs to be said for once:
What kind of sorry luser are you that you think I would care about the name
on any posting (short of pseudonyms, which is another issue), that I would
actually care to use the little free time I have to target your (or
anyone's) postings specifically? You need to be strong now: You are not
that important (to me).
You have to face the fact that so far you happen to have been posting mostly
bad code. It does not matter if that code was just an example. A bad
example is a bad example. It is misleading at best.
So it boils down to this: If you do not want your code to be commented on,
do not post it. If you want more favorable comments from me on your code
(which is entirely possible), post better code. As for examples, you should
post better examples.
And I encourage you and everyone else to discuss *my* code with me, in
public if you want. Many have found that rewarding already, and so do I.
But you better bring good arguments.
> On 2012-10-24 21:57, Thomas 'PointedEars' Lahn wrote:
>>> // DOM0 event handler
>>> document.onclick = function (evt) {
>>> var e = evt || window.event;
>>> ...
>>> };
>>
>> This is error-prone if `evt' refers to a host object, and unnecessarily
>> inefficient. And document.onclick?
>
> This is a simple example of one very common usage of the || operator,
> not an endorsement of DOM0-style event handling, so yes, document.onclick.
>
> As for error-prone, that's a huge exaggeration.
I do not see how "error-prone" can be exaggerated. This code is prone to
errors by the very nature of host objects; IOW, it is error-prone.
> It's true that the event object is a host object,
So you noticed.
> but this particular form of checking for an event object as the first
> argument has been widely used without problems since the mid 90s.
> Defensive programming is a good habit, but it can be carried to far.
It is not logical to use an approach that is prone to more errors than
another approach, especially when that other approach is simpler, too.
> And "inefficient"?
Yes, *unnecessarily* inefficient *by comparison*.
> In a click handler?
Yes, especially in event _listeners_.
> This statement will be evaluated (at most) once every time the user
> clicks.
If that was true, what do you need the _listener_ for, then?
> I'm quite certain that any difference in performance between this example
> and whatever you would offer as an alternative cannot even be measured
> under these circumstances.
Your logic is flawed. The performance benefit of `||' is negligible, too.
>>> // initialize a "namespace" object without overwriting it
>>> var myLib = myLib || {};
>>
>> This is unnecessarily complicated. An `if' statement will do better and
>> will be slightly more efficient.
>
> So you would prefer one of these?
>
> if (!myLib) {
> var myLib = {};
> }
>
> if (typeof myLib == "undefined") {
> var myLib = {};
> }
I am preferring the second one in JSX.
> What I wrote looks less complicated to me,
YMMV. I think it is easier to explain with the `if' statement – especially
to a beginner – why the variable may have the `undefined' value before
assignment, and why the assignment would not take place when it has not.
> but in the end it's just a matter of personal taste.
No, because your approach, and the first alternative to that which you
offered, performs implicit type conversion, and cannot be easily adapted to
other properties; mine does not, and can be, respectively.
> As with the first example, the efficiency of this statement is completely
> irrelevant in the typical case (i.e., at the beginning of an included
> file). Your version may save a single assignment, and only if myLib
> already exists. Why worry about such details?
Your logic is flawed. Why worry about using `||' to begin with? Because it
looks cool?
>>> myLib.myFunc = function () { ... };
>>>
>>> // call a method on an optional argument
>>> function findParagraphs (parentEle) {
>>> return (parentEle || document).getElementsByTagName("p");
>>> }
>>
>> This can be error-prone. In particular, there is a problem when
>> expression in the `||' operation is a reference to a Function instance.
>> Some functions can only be called as methods of an (specific) object.
>
> You're imagining things, my overly critical friend.
No, and I am not your friend.
> As you can guess from the code, this function is intended to be called
> with an element node, or no arguments. Pass an unsupported argument and
> you will get an error. If that's your definition of error-prone, you will
> need to check each end every argument in every single function. Sure,
> that's possible, but if you do that, stop complaining about inefficient
> code.
Your function will fail if the element object in question does not implement
the getElementsByTagName() method, and it will do so in a way that is hard
to debug.
>>> // combining && and ||
>>> function textOfFirst (parentEle, eleName) {
>>> var ele = parentEle.getElementsByTagName(eleName)[0];
>>> return ele && ele.firstChild && ele.firstChild.data || "";
>>> }
>>
>> This is error-prone as the return type would vary (one of Null, Element
>> or descendant, Text, or String) depending on runtime conditions that one
>> has virtually no control over. (In fact, the first line is error-prone
>> already as null has no properties). To be avoided.
>
> Please explain how this function can possibly return anything other than
> a string (under non-pathological* circumstances).
Yes, I was mistaken. In fact, calling the function can only have the
following outcomes under those constraints:
- A `TypeError' exception is thrown because a value that refers to
or can be converted to an object was not passed for `parentEle';
- A `TypeError' exception is thrown because the object referred to by
`parentEle' does not implement the getElementsByTagName() method;
- A `TypeError' exception is thrown because the getElementsByTagName()
method returns `null';
- A non-empty value of type String is returned, which may or may not be
the full text content of the first child text node, if any;
- "" of type String is returned.
> Again, if you insist on passing unsupported arguments to a function, you
> deserve what you get.
Obviously you have not thought this through sufficiently.
PointedEars
--
Danny Goodman's books are out of date and teach practices that are
positively harmful for cross-browser scripting.
-- Richard Cornford, cljs, <cife6q$253$1$8300dec7@news.demon.co.uk> (2004)
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott.sauyet@gmail.com> |
|---|---|
| Date | 2012-10-26 08:24 -0700 |
| Message-ID | <eb4cb4f7-db01-4490-bff1-df7a1590c143@c16g2000yqe.googlegroups.com> |
| In reply to | #16873 |
Thomas 'PointedEars' Lahn wrote:
> Stefan Weiss wrote:
>> I've been waiting for this... It seems that every time I post code to
>> this group, I get a reply filled with pedantic nitpicks and irrelevant
>> criticism from you. I do enjoy constructive feedback, but all this
>> disagreeing for the sake of disagreeing is a waste of everyone's time.
>> Especially when you intentionally misinterpret short code examples as
>> something they were never meant to be.
>
> I did not want to comment on that nonsense anymore, but I am finding now
> that it needs to be said for once:
>
> What kind of sorry luser are you that you think I would care about the name
> on any posting (short of pseudonyms, which is another issue), that I would
> actually care to use the little free time I have to target your (or
> anyone's) postings specifically? You need to be strong now: You are not
> that important (to me).
I for one did not read Stefan's post as suggesting that you, Thomas,
had any particular animus for him. Rather, he seemed to be critiquing
your habit of picking nits. You certainly must recognize that you
have a reputation for doing so.
> You have to face the fact that so far you happen to have been posting mostly
> bad code. [ ... ]
You have to face the fact that many of us disagree. Most of the code
I've seen Stefan post has been quite good.
>> On 2012-10-24 21:57, Thomas 'PointedEars' Lahn wrote:
>>>> // DOM0 event handler
>>>> document.onclick = function (evt) {
>>>> var e = evt || window.event;
>>>> ...
>>>> };
>
>>> This is error-prone if `evt' refers to a host object, and unnecessarily
>>> inefficient. And document.onclick?
>
>> This is a simple example of one very common usage of the || operator,
>> not an endorsement of DOM0-style event handling, so yes, document.onclick.
>
>> As for error-prone, that's a huge exaggeration.
>
> I do not see how "error-prone" can be exaggerated. This code is prone to
> errors by the very nature of host objects; IOW, it is error-prone.
"Likely to suffer from errors" is probably the best simple definition
of "error-prone". "Likely" is a word very easy to exaggerate. As
Stefan points out, this very common idiom and it's been years since
I've heard a report of an error based on it over some very large
codebases I've had to maintain. I don't see it likely to suffer from
errors. Do you have evidence that it is? Note that "likely" and
"possible" are not even close to synonymous.
>> It's true that the event object is a host object,
>
> So you noticed.
>
>> but this particular form of checking for an event object as the first
>> argument has been widely used without problems since the mid 90s.
>> Defensive programming is a good habit, but it can be carried to far.
>
> It is not logical to use an approach that is prone to more errors than
> another approach, especially when that other approach is simpler, too.
What approach do you recommend?
> [ ... ]
>> This statement will be evaluated (at most) once every time the user
>> clicks.
>
> If that was true, what do you need the _listener_ for, then?
Are you suggesting that it's not true?
>> I'm quite certain that any difference in performance between this example
>> and whatever you would offer as an alternative cannot even be measured
>> under these circumstances.
>
> Your logic is flawed. The performance benefit of `||' is negligible, too.
Do you really think Stefan or others were promoting the logical-or for
its efficiency? Please check your logic. You brought up
inefficiency. He rebutted, noting that this is run on user click
events, hardly an environment where the differences unlikely to total
more than a few hundred microseconds are likely to matter.
So why did you mention that this is inefficient in this context? Do
you have some rationale?
But Stefan does not have to defend arguments about performance. He
made no such arguments. You did.
>>>> // initialize a "namespace" object without overwriting it
>>>> var myLib = myLib || {};
>
>>> This is unnecessarily complicated. An `if' statement will do better and
>>> will be slightly more efficient.
>
>> So you would prefer one of these?
>
>> if (!myLib) {
>> var myLib = {};
>> }
>
>> if (typeof myLib == "undefined") {
>> var myLib = {};
>> }
>
> I am preferring the second one in JSX.
>
>> What I wrote looks less complicated to me,
>
> YMMV. I think it is easier to explain with the `if' statement – especially
> to a beginner – why the variable may have the `undefined' value before
> assignment, and why the assignment would not take place when it has not.
>
>> but in the end it's just a matter of personal taste.
>
> No, because your approach, and the first alternative to that which you
> offered, performs implicit type conversion, and cannot be easily adapted to
> other properties; mine does not, and can be, respectively.
Why should I mind that this approach performs implicit type
conversion? I'm working in a dynamically-typed language; I've quite
come to expect that.
Why should I worry that this approach cannot be easily adapted to
other properties? It's being used once at the top of each file in a
very distinct way to ensure that the namespace I need has been
properly initialized. I feel no need to make this look particularly
similar to other parts of the code. On the other hand, I do want to
make it concise and straightforward. Stefan's formulation does that.
I'm using this less and less as I move to AMD-style module loading,
but when I do use namespaces, I generally use this technique. Again,
I think you're pressing something that matters little.
>> As with the first example, the efficiency of this statement is completely
>> irrelevant in the typical case (i.e., at the beginning of an included
>> file). Your version may save a single assignment, and only if myLib
>> already exists. Why worry about such details?
>
> Your logic is flawed. Why worry about using `||' to begin with? Because it
> looks cool?
Why do you think Stefan is worried about using it? Your question
sounds to me similar to "Why worry about using `else' to begin with?"
You could certainly write programs with the same behavior without ever
coding an `else' statement. So why would you bother? It's just one
of the tools offered by the language that he chooses to use. If it
offers an elegant way to solve a problem, it's often worth using.
>>>> myLib.myFunc = function () { ... };
>
>>>> // call a method on an optional argument
>>>> function findParagraphs (parentEle) {
>>>> return (parentEle || document).getElementsByTagName("p");
>>>> }
>
>>> This can be error-prone. In particular, there is a problem when
>>> expression in the `||' operation is a reference to a Function instance.
>>> Some functions can only be called as methods of an (specific) object.
Do you have examples of that? I've never run across that.
> [ ... ]
>> As you can guess from the code, this function is intended to be called
>> with an element node, or no arguments. Pass an unsupported argument and
>> you will get an error. If that's your definition of error-prone, you will
>> need to check each end every argument in every single function. Sure,
>> that's possible, but if you do that, stop complaining about inefficient
>> code.
>
> Your function will fail if the element object in question does not implement
> the getElementsByTagName() method, and it will do so in a way that is hard
> to debug.
So, to Stefan's point, would you suggest that such a function check
the argument for conformance and accept the performance hit entailed?
Or do you think that it's all right in some code to assume that the
calling code will be configured correctly? Does it matter how
reusable this code is supposed to be, or do you have the same
standards for a one-off single-developer project and a library meant
to share with a broad community?
> [ argument elided ]
>> Again, if you insist on passing unsupported arguments to a function, you
>> deserve what you get.
>
> Obviously you have not thought this through sufficiently.
Do you really believe that if someone disagrees with you that they
have always not thought things through sufficiently? Obviously you
know Stefan; he's been here a while; he's been a consistent
contributor. Do you not think its possible that on some topics he
might have thought things through even more completely than you have
and come to a different conclusion?
-- Scott
[toc] | [prev] | [next] | [standalone]
| From | Stefan Weiss <krewecherl@gmail.com> |
|---|---|
| Date | 2012-11-07 22:13 +0100 |
| Message-ID | <k7eitp$b68$1@news.albasani.net> |
| In reply to | #16873 |
On 2012-10-25 23:18, Thomas 'PointedEars' Lahn wrote: > What kind of sorry luser are you [...] If you have to resort to name-calling, this is EOD for me. Most of what I would have replied has already been covered by Scott. Food for thought: For a comp.lang group focussing on one of the fastest growing languages, there are unusually few people here who will volunteer actual code examples when answering questions. IMO, one of the main reasons for that is the high probability of getting one of your long-winded, pedantic replies. I love discussing code, and I love getting constructive feedback on my code, but what you're doing is something entirely different: you look for minor details to criticize in other people's code, and you do so in a very aggressive, arrogant manner. Your replies are littered with (usually unqualified) comments like "error-prone", "inefficient", "rubbish", "utter nonsense", "you are missing the point", etc, which would practically force the author to post another reply and refute your claims. I don't know about the other regulars, but the prospect of getting into another pointless sparring match with you has often led me to discard a reply instead of posting it. I just don't have the time for this. - stefan
[toc] | [prev] | [next] | [standalone]
| From | Tim Streater <timstreater@greenbee.net> |
|---|---|
| Date | 2012-11-07 21:51 +0000 |
| Message-ID | <timstreater-F0F4F6.21513907112012@news.individual.net> |
| In reply to | #17065 |
In article <k7eitp$b68$1@news.albasani.net>, Stefan Weiss <krewecherl@gmail.com> wrote: > On 2012-10-25 23:18, Thomas 'PointedEars' Lahn wrote: > > What kind of sorry luser are you [...] > > If you have to resort to name-calling, this is EOD for me. Most of what > I would have replied has already been covered by Scott. > > Food for thought: > > For a comp.lang group focussing on one of the fastest growing languages, > there are unusually few people here who will volunteer actual code > examples when answering questions. IMO, one of the main reasons for that > is the high probability of getting one of your long-winded, pedantic > replies. I love discussing code, and I love getting constructive > feedback on my code, but what you're doing is something entirely > different: you look for minor details to criticize in other people's > code, and you do so in a very aggressive, arrogant manner. Your replies > are littered with (usually unqualified) comments like "error-prone", > "inefficient", "rubbish", "utter nonsense", "you are missing the point", > etc, which would practically force the author to post another reply and > refute your claims. I don't know about the other regulars, but the > prospect of getting into another pointless sparring match with you has > often led me to discard a reply instead of posting it. I just don't have > the time for this. Precisely why I tell him to fuck off from time to time. It's good for his health. Your observations are 100% correct, by the way. -- Tim "That excessive bail ought not to be required, nor excessive fines imposed, nor cruel and unusual punishments inflicted" -- Bill of Rights 1689
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.javascript
csiph-web