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 | 13 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 6 of 6 — ← Prev page 1 2 3 4 5 [6]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-18 13:37 +0100 |
| Message-ID | <0qGdnW4DceWJZeLNnZ2dnUVZ_gadnZ2d@earthlink.com> |
| In reply to | #16707 |
Jukka K. Korpela wrote:
...
> A formal parameter has no type. Its values may have types. When you call
> foo(42), then the formal parameter gets the value 42, a number. When you
> call foo('a'), it gets the value 'a', a string. There is no point in
> confusing this by saying that parameters or variables have types.
>
So your position is that a variable always has a value, possibly the
undefined value, and the type belongs to the current value. Is that correct?
> However, it is essential to note that the mechanisms of the language do
> not protect you from "type errors" in the sense as in many other
> languages where you get a compile-time or run-time message about
> assignment of a value of a wrong type. Neither do you get automatic type
> conversions based on the type of a variable - simply because variables
> do not have types in JavaScript.
>
Yes, I've noticed that, and understand that if I really need e.g. a
parameter to be a number, I need to check that at run time.
Patricia
[toc] | [prev] | [next] | [standalone]
| From | "Jukka K. Korpela" <jkorpela@cs.tut.fi> |
|---|---|
| Date | 2012-10-18 15:55 +0300 |
| Message-ID | <k5ou8b$kur$1@dont-email.me> |
| In reply to | #16708 |
2012-10-18 15:37, Patricia Shanahan wrote: > So your position is that a variable always has a value, possibly the > undefined value, and the type belongs to the current value. Is that > correct? Yes. And this is what the ECMAScript standard says. It describes types of values, but not types of values at all. Right before clause 4.2.1 it says: "For example, a variable is not required to have its type declared nor are types associated with properties". The first part might be misleading - it's not just that they are not required to have their types declared, they *cannot* have their types declared, as becomes clear after reading the standard and seeing that there is no construct for the purpose. >> However, it is essential to note that the mechanisms of the language >> do not protect you from "type errors" in the sense as in many other >> languages where you get a compile-time or run-time message about >> assignment of a value of a wrong type. Neither do you get automatic >> type conversions based on the type of a variable - simply because >> variables do not have types in JavaScript. > > Yes, I've noticed that, and understand that if I really need e.g. a > parameter to be a number, I need to check that at run time. Well, you could also rely on automatic type conversions. Whether this is good practice is debatable (and depends), but the point is that type conversions do take place in JavaScript - but not according to the type of a variable. The conversions depend on the *use* of *values*. Consider this: var a = 10; a = a + '5'; Here the original value of a gets converted to a string, because the value is used in an expression with the "+" operator and a string as the other operand. So '10' and '5' are concatenated, yielding '105'. This does not depend on the type of the variable a at all (it has no type); the same conversion appears when an expression has just literals as operands: 10 + '5'. -- Yucca, http://www.cs.tut.fi/~jkorpela/
[toc] | [prev] | [next] | [standalone]
| From | John G Harris <john@nospam.demon.co.uk> |
|---|---|
| Date | 2012-10-19 10:12 +0100 |
| Message-ID | <Z77qcZFamRgQFwrG@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD> |
| In reply to | #16708 |
On Thu, 18 Oct 2012 at 13:37:37, in comp.lang.javascript, Patricia Shanahan wrote: <snip> >Yes, I've noticed that, and understand that if I really need e.g. a >parameter to be a number, I need to check that at run time. There is an alternative. You write a pre-condition, as a comment, saying e.g Pre: n is a number. And you obey it. Of course, if you are disorganised or have disorganised co-workers who refuse to take any notice of other people's rules then that won't work. Instead, you will have to check that n really is a number. This takes coding time, testing time, and program execution time, all of which is wasted as n is always a number. John -- John Harris
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-19 07:24 -0700 |
| Message-ID | <O4KdnbZ6xu8b_xzNnZ2dnUVZ_rSdnZ2d@earthlink.com> |
| In reply to | #16734 |
On 10/19/2012 2:12 AM, John G Harris wrote: > On Thu, 18 Oct 2012 at 13:37:37, in comp.lang.javascript, Patricia > Shanahan wrote: > > <snip> >> Yes, I've noticed that, and understand that if I really need e.g. a >> parameter to be a number, I need to check that at run time. > > There is an alternative. You write a pre-condition, as a comment, saying > e.g Pre: n is a number. And you obey it. > > Of course, if you are disorganised or have disorganised co-workers who > refuse to take any notice of other people's rules then that won't work. > Instead, you will have to check that n really is a number. This takes > coding time, testing time, and program execution time, all of which is > wasted as n is always a number. I think it is a matter of balance. When programming in C, which has type rules but also has a lot of ways of breaking them, I found it helpful to check reasonableness of data at major component boundaries. I am not a perfect programmer, especially when programming in a language I started learning about a month ago, and checks can make it much easier to track down a bug. On the other hand, checking everything at every call can lead to massive code bloat. There are definitely situations in which it is best to trust the caller to make the preconditions true. Patricia
[toc] | [prev] | [next] | [standalone]
| From | John G Harris <john@nospam.demon.co.uk> |
|---|---|
| Date | 2012-10-20 17:47 +0100 |
| Message-ID | <8JyA$NDRWtgQFwse@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD> |
| In reply to | #16736 |
On Fri, 19 Oct 2012 at 07:24:06, in comp.lang.javascript, Patricia Shanahan wrote: >On 10/19/2012 2:12 AM, John G Harris wrote: >> On Thu, 18 Oct 2012 at 13:37:37, in comp.lang.javascript, Patricia >> Shanahan wrote: >> >> <snip> >>> Yes, I've noticed that, and understand that if I really need e.g. a >>> parameter to be a number, I need to check that at run time. >> >> There is an alternative. You write a pre-condition, as a comment, saying >> e.g Pre: n is a number. And you obey it. >> >> Of course, if you are disorganised or have disorganised co-workers who >> refuse to take any notice of other people's rules then that won't work. >> Instead, you will have to check that n really is a number. This takes >> coding time, testing time, and program execution time, all of which is >> wasted as n is always a number. > >I think it is a matter of balance. When programming in C, which has type >rules but also has a lot of ways of breaking them, I found it helpful to >check reasonableness of data at major component boundaries. I am not a >perfect programmer, especially when programming in a language I started >learning about a month ago, and checks can make it much easier to track >down a bug. > >On the other hand, checking everything at every call can lead to massive >code bloat. There are definitely situations in which it is best to trust >the caller to make the preconditions true. > That's an organised way to do it :-) John -- John Harris
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 01:15 +0100 |
| Message-ID | <3469358.shaKaQI8qd@PointedEars.de> |
| In reply to | #16708 |
Patricia Shanahan wrote:
> Jukka K. Korpela wrote:
>> A formal parameter has no type. Its values may have types. When you call
>> foo(42), then the formal parameter gets the value 42, a number. When you
>> call foo('a'), it gets the value 'a', a string. There is no point in
>> confusing this by saying that parameters or variables have types.
>
> So your position is that a variable always has a value, possibly the
> undefined value, and the type belongs to the current value. Is that
> correct?
Your understanding is correct; your understanding of the position is not,
because the position is not correct.
Like a local variable, a formal parameter only has meaning in the local
execution context of the function. There it does have a type: the type of
the argument that was passed for it, if any.
It is important to know the difference between arguments and (formal)
parameters. A function can be passed arguments for which there is no formal
(named) parameter; those can be accessed with the arguments object. On the
other hand, the type of a parameter for which no argument has been passed is
Undefined.
Similarly, any variable has a type at runtime: the type of the expression at
last assignment (which may be Undefined), or Undefined. If it was not
initialized, i. e. had never been assigned a value explicitly, its type was
Undefined.
In
/**
* Foos a bar and returns it.
*
* @param x : Object|String
* @param y : Number
* @return {String} The fooed bar.
*/
function foo (x, y)
{
var z;
console.log(x, y, arguments[2], z);
return x;
}
foo(bar, baz, 42);
`foo' is the function identifier, and the values of `bar' and `baz' are
arguments to the function. `x' and `y' are formal parameters of the
function for which the values of `bar' and `baz' have been passed as
arguments. A third argument has been passed to the function which is not
accessible by name (because there is no parameter for it), but through the
`arguments' object; its `2' property specifies that third argument (0-based
indexing). The types of `x' and `y' at runtime are the types of the values
of `bar' and `baz', respectively. The value of `z' is `undefined', of type
Undefined, at runtime *here*, because it would have been never assigned a
value explicitly.
The *expected* types for those parameters are to be documented, so that the
function/method can be used properly. IOW, a user of the function should
not expect it to work properly if arguments of an undocumented type had been
passed (but they can expect the function to be callable). (AISB, be very
careful with overloading.)
>> However, it is essential to note that the mechanisms of the language do
>> not protect you from "type errors" in the sense as in many other
>> languages where you get a compile-time or run-time message about
>> assignment of a value of a wrong type.
Correct. That follows from the languages using *dynamic* (run-time) typing
as opposed to *static* (compile-time) typing.
>> Neither do you get automatic type conversions based on the type of a
>> variable - simply because variables do not have types in JavaScript.
Nonsense. AISB, all variables do have a type. They only do not have a
(specific) type at compile time. They do have one *at runtime*.
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 | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 01:31 +0100 |
| Message-ID | <18045452.nWmfJZpC4k@PointedEars.de> |
| In reply to | #16823 |
Thomas 'PointedEars' Lahn wrote:
> The *expected* types for those parameters are to be documented, so that
^ and arguments
> the function/method can be used properly. IOW, a user of the function
> should not expect it to work properly if arguments of an undocumented type
> had been passed (but they can expect the function to be callable). (AISB,
> be very careful with overloading.)
It should also be noted that static code analysis can use those comments not
only to provide live documentation (as in outlines and tooltips), but also
to show possible problems with the code while writing it. Eclipse JSDT
(JavaScript Development Tools) are capable of that; any decent JS/ES IDE
should be. [Unfortunately, there is no standard for documentation comments
such as Javadoc yet; the current jsdoc-toolkit's style – which is based on
the former JSDoc – is extensive and useful (in particular with JSDT), but
not adequate in several respects.]
PointedEars
--
Prototype.js was written by people who don't know javascript for people
who don't know javascript. People who don't know javascript are not
the best source of advice on designing systems that use javascript.
-- Richard Cornford, cljs, <f806at$ail$1$8300dec7@news.demon.co.uk>
[toc] | [prev] | [next] | [standalone]
| From | "Jukka K. Korpela" <jkorpela@cs.tut.fi> |
|---|---|
| Date | 2012-10-24 07:34 +0300 |
| Message-ID | <k67r43$ufi$1@dont-email.me> |
| In reply to | #16823 |
2012-10-24 3:15, Thomas 'PointedEars' Lahn wrote: > AISB, all variables do have a type. The resident troll’s attempt at confusing people was not this time accompanied with his usual babbling “there is no JavaScript” and with references to the ECMAScript standard. No wonder, since he knows quite well that the standard says nothing about the type of a variable. -- Yucca, http://www.cs.tut.fi/~jkorpela/
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 19:57 +0200 |
| Message-ID | <3615430.ttrsPfDsFo@PointedEars.de> |
| In reply to | #16830 |
Jukka K. Korpela wrote: > 2012-10-24 3:15, Thomas 'PointedEars' Lahn wrote: >> AISB, all variables do have a type. > > The resident troll’s attempt at confusing people was not this time > accompanied with his usual babbling “there is no JavaScript” and with > references to the ECMAScript standard. No wonder, since he knows quite > well that the standard says nothing about the type of a variable. Your inability to read in context (in addition to your ongoing anti-social behavior) is your problem alone. Variables have values; values are associated with a type. The ECMAScript Language Specification, too, is very clear about that, particularly in section 8 of the 5.1 Edition. And yes, I do know the Specification and its implementations quite well; eventually I wrote a bachelor's thesis about them. PointedEars -- When all you know is jQuery, every problem looks $(olvable).
[toc] | [prev] | [next] | [standalone]
| From | "Jukka K. Korpela" <jkorpela@cs.tut.fi> |
|---|---|
| Date | 2012-10-24 21:02 +0300 |
| Message-ID | <k69agf$9s2$1@dont-email.me> |
| In reply to | #16833 |
2012-10-24 20:57, Thomas 'PointedEars' Lahn wrote: > Jukka K. Korpela wrote: > >> 2012-10-24 3:15, Thomas 'PointedEars' Lahn wrote: >>> AISB, all variables do have a type. >> >> The resident troll’s attempt at confusing people was not this time >> accompanied with his usual babbling “there is no JavaScript” and with >> references to the ECMAScript standard. No wonder, since he knows quite >> well that the standard says nothing about the type of a variable. > > Your inability to read in context (in addition to your ongoing anti-social > behavior) is your problem alone. Variables have values; values are > associated with a type. The ECMAScript Language Specification, too, is very > clear about that, particularly in section 8 of the 5.1 Edition. And yes, I > do know the Specification and its implementations quite well; eventually I > wrote a bachelor's thesis about them. It almost looks like the resident troll has been automated. The comment looks like boilerplate text, with some parameterized insults, sent by a bot with no regard to content. After all, the troll posting says that variables have values and values have types, without even trying to claim (any more) that variables have types. -- Yucca, http://www.cs.tut.fi/~jkorpela/
[toc] | [prev] | [next] | [standalone]
| From | Patricia Shanahan <pats@acm.org> |
|---|---|
| Date | 2012-10-18 20:15 -0700 |
| Message-ID | <GfmdnTybxcA-WB3NnZ2dnUVZ_qqdnZ2d@earthlink.com> |
| In reply to | #16707 |
On 10/18/2012 5:32 AM, Jukka K. Korpela wrote: ... > However, it is essential to note that the mechanisms of the language do > not protect you from "type errors" in the sense as in many other > languages where you get a compile-time or run-time message about > assignment of a value of a wrong type. Neither do you get automatic type > conversions based on the type of a variable - simply because variables > do not have types in JavaScript. > I just spent most of an 11 hour flight doing some programming. I've already found one adjustment I need to make. It is worth while writing a very, very simple test of each function. That makes it easier to track down the typos that completely break a function. Patricia
[toc] | [prev] | [next] | [standalone]
| From | Thomas 'PointedEars' Lahn <PointedEars@web.de> |
|---|---|
| Date | 2012-10-24 01:21 +0100 |
| Message-ID | <15740262.UMIpHFasVP@PointedEars.de> |
| In reply to | #16706 |
Patricia Shanahan wrote: > Thomas 'PointedEars' Lahn wrote: >> Patricia Shanahan wrote: >>> It is perhaps natural because I have been programming so long in >>> more strongly typed languages. >>> >>> Is it a problem? >> >> With that "much" information, I have to say yes. > > The good news is that I do understand the problem of trying to program > in language X as though it were language Y. People who do that end up > programming in a very unsatisfactory language containing only the > features that are in common to the two languages, and work the same way > in both of them. ACK. >>> On the one hand, it makes for very organized code, with a lot of >>> opportunities for adding type-checking assertions, generally a good >>> thing. On the other hand, I may be missing out on opportunities to make >>> my code simpler and a better fit for the language. >>> >>> Is it enough to be aware of the dynamic aspects of the language, and be >>> prepared to use them when strong typing gets in the way? >> >> (see above) >> >> No. (However, contrary to common misconception, there are no "untyped >> variables". Implementations of ECMAScript Ed. 1 to 3, 5, and 5.1 are >> dynamically and weakly typed, not untyped. Uninitialized variables and >> trailing parameters for which no argument has been passed, hold the >> `undefined' value, the sole value of the Undefined type.) > > As I understand the issue, a variable always has a type, but that type > can change on assignment. Similarly, the type of a formal parameter is > determined by the type of the actual parameter in the call, or, as you > say, the Undefined type if the call did not supply an actual parameter. Correct. "Dynamically typed" (as opposed to "statically typed") means that the type of an expression is determined on runtime, not compile time. "Weakly typed" (as opposed to "strongly typed") means implicit type conversion of a value if an operation requires it. The latter is a very powerful feature; but keep in mind that power corrupts ;-) > This is obviously significantly different from having a type that is > fixed at declaration, and I need to wrap my brain around the implications. One implication is that you have optional parameters for free. You can access the `arguments.length' property to find out how many arguments have been passed, and access them with arguments[n] (where n is a 0-based index). Another is that overloading is only as useful as one is able to differentiate between the different argument types and values (so for example, because host objects do not need to exhibit exactly specified behavior, you should not require references to them as parameters of overloaded method. Overloading and host objects do not mix. Many popular libraries make that mistake and are inherently unreliable as a a result.) PointedEars -- Use any version of Microsoft Frontpage to create your site. (This won't prevent people from viewing your source, but no one will want to steal it.) -- from <http://www.vortex-webdesign.com/help/hidesource.htm> (404-comp.)
[toc] | [prev] | [next] | [standalone]
| From | Scott Sauyet <scott.sauyet@gmail.com> |
|---|---|
| Date | 2012-10-21 17:57 -0700 |
| Message-ID | <1ee23d3c-644e-428b-a35c-6ab8e60fb059@x18g2000vby.googlegroups.com> |
| In reply to | #16703 |
Patricia Shanahan wrote:
> I've just started writing some of my production code, as distinct from
> throw-away tests and practice programs. I find myself writing in a style
> that would work in a strongly typed language. I know the intended type
> of each identifier, and find myself recording types in comments.
>
> It is perhaps natural because I have been programming so long in
> more strongly typed languages.
>
> Is it a problem?
Not exactly. But as you seem to suspect, there are fundamental
disconnects when you try to use Javascript as though it were just like
some particular other language. If you've spent much more time in
strongly-typed languages, this might be a significant difference. But
I think for most people, the hardest adjustment is to the more
functional aspects of the language.
Between the name and the superficial syntax, it's hard to escape the
idea that this language is much like Java, and by extension, like C/C+
+/C#. But the creator of the language was tempted to Netscape in
order to "implement Scheme in the browser". His idea was to write a
functional, LISP-like language. Marketing deals between Netscape and
Sun ended up dictating some of the syntax, and left us with certain
terrible designs, like an extremely poorly conceived Date API, but we
also have first-class functions, function-scoping, closures, and other
features more common to functional languages.
Not taking advantage of these, or trying to code as though you're in
C#, are what can really steer you wrong. Looking for stronger typing
that the language offers is minor in comparison, especially as you can
achieve some degree of this with means already discussed in this
thread. There are also similar languages with stronger type-safety,
either sibling languages such as ActionScript, or ones that extend
Javascript with features like stronger types, such as the brand new
TypeScript. I wouldn't recommend any of them, although certain other
languages that compile into Javascript are fairly interesting. But
they demonstrate that many others do find Javascript's dynamic typing
problematic. Try it, though. I, for one, find it quite liberating.
> On the one hand, it makes for very organized code, with a lot of
> opportunities for adding type-checking assertions, generally a good
> thing. On the other hand, I may be missing out on opportunities to make
> my code simpler and a better fit for the language.
>
> Is it enough to be aware of the dynamic aspects of the language, and be
> prepared to use them when strong typing gets in the way?
Not quite. You should probably become familiar with some of the
common idioms of the language, and at least decide if you want to use
them rather than their more type-safe alternative.
if (val) {
// ...
}
// instead of
if (typeof val == "string" and val != "") {
// ..
}
The above could fail if val were the boolean `true`, any non-zero
number, any Object, and yet it is used widely and with little worry in
much of the Javascript community. Of course, you might not want to
use it in code where `val` is supplied by untrusted code, but that
sort of trade-off is made all the time in the community.
The point is that you can write efficient and effective code with the
language, but you will have to decide what degree of type-safety you
need. If you're used to a high degree of it, especially when managed
by a compiler, it may seem especially risky. But if you've worked
with dynamically typed languages for a while, you might find you never
want to go back because, surprisingly, those sort of errors just never
seem to bite you.
-- Scott
[toc] | [prev] | [standalone]
Page 6 of 6 — ← Prev page 1 2 3 4 5 [6]
Back to top | Article view | comp.lang.javascript
csiph-web