I'm writing some ASP using js and I need to do a case sensitive SQL
select. Googling gave me this:
SELECT * FROM User WHERE Strcomp("Blue",[Password],vbBinaryCompare)=0
Strcomp is from vbs. Is there a js equivalent, or some other way to
handle this?
Andrew Poulos
32  4000 
Andrew Poulos wrote:
I'm writing some ASP using js and I need to do a case sensitive SQL
select. Googling gave me this:
SELECT * FROM User WHERE Strcomp("Blue",[Password],vbBinaryCompare)=0
Strcomp is from vbs. Is there a js equivalent, or some other way to
handle this?
As long as we're talking about binary comparisons (StrComp's default,
zero), then I think the following should so the trick:
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>javascript binary Strcomp</title>
</head>
<body>
<table border="1">
<tr><th>VBS</th><th>JS</th></tr>
<tr><td>
<script language="vbscript" type="text/vbscript">
document.write(Strcomp("Blue","blue",0))
document.write(" <BR>")
document.write(Strcomp("blue","blue",0))
document.write(" <BR>")
document.write(Strcomp("blue","Blue",0))
document.write(" <BR>")
document.write(Strcomp("blues","Blue",0))
document.write(" <BR>")
document.write(Strcomp("123","abc",0))
document.write(" <BR>")
document.write(Strcomp("foo","bar",0))
document.write(" <BR>")
document.write(Strcomp("0","01",0))
</script>
</td>
<td>
<script language="javascript" type="text/javascript">
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
document.write(nr + " <BR>")
}
js_Strcomp_binary("Blue","blue")
js_Strcomp_binary("blue","blue")
js_Strcomp_binary("blue","Blue")
js_Strcomp_binary("blues","Blue")
js_Strcomp_binary("123","abc")
js_Strcomp_binary("foo","bar")
js_Strcomp_binary("0","01")
</script>
</td></tr>
</table>
</body>
</html>
Hope this helps,
--
Bart
Bart Van der Donck wrote:
[...]
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
Oops, I forgot to add the following here:
if (!v1||!v2) nr = null
document.write(nr + " <BR>")
}
--
Bart
Bart Van der Donck wrote:
Bart Van der Donck wrote:
[...]
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
Oops, I forgot to add the following here:
if (!v1||!v2) nr = null
document.write(nr + " <BR>")
}
It worth mention that String on modern UAs has native localeCompare
method which is especially priceless for non-ASCII strings comparison.
Besides that it returns shuttle value (-1, 0, 1) by default:
var a = 'abcd';
var b = 'efgh';
alert(a.localeCompare(b));
IE and Firefox both support it.
P.S. Where is the snow? Winter in Europe... you must be kidding... if I
knew I would go to Tahoe... :-) :-(
VK wrote:
Bart Van der Donck wrote:
Bart Van der Donck wrote:
[...]
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
Oops, I forgot to add the following here:
if (!v1||!v2) nr = null
document.write(nr + " <BR>")
}
It worth mention that String on modern UAs has native localeCompare
method which is especially priceless for non-ASCII strings comparison.
Besides that it returns shuttle value (-1, 0, 1) by default:
var a = 'abcd';
var b = 'efgh';
alert(a.localeCompare(b));
Except that it doesn't return null if one of the two strings is
undefined:
javascript :
alert('abc'.localeCompare(null)) // says '-1'
vbscript :
alert(Strcomp("abc",null)) // says 'null'
--
Bart
VK wrote:
Bart Van der Donck wrote:
>Bart Van der Donck wrote:
>>[...]
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
Oops, I forgot to add the following here:
if (!v1||!v2) nr = null
Empty strings are valid subjects for comparison so null should not be
returned if either string is empty. This is a case where
type-converting comparison (==) with null is the appropriate test as
both null and undefined equal null, but no string ever would.
>> document.write(nr + " <BR>")
}
It worth mention that String on modern UAs has native localeCompare
method which is especially priceless for non-ASCII strings comparison.
When all javascript strings are internally 16 bit code points it makes
no difference to a comparison whether the characters are non-ASCII or
not.
The - localCompare - method takes into account location dependent
ordering rules while doing text-based comparisons. The Strcomp function
without a third argument does binary comparisons. Thus - localCompare -
is an inappropriate suggestion as javascript's normal string comparison
by code point value is the required behaviour.
Besides that it returns shuttle value (-1, 0, 1) by default:
It returns implementation dependent values where equality being zero
and the sign of non-equal values is all that is specified.
var a = 'abcd';
var b = 'efgh';
alert(a.localeCompare(b));
IE and Firefox both support it.
<snip>
The - localCompare - method is specified in ECMA 262, 3rd Ed. so all
3rd Edition conforming implementations will support it, including IE
and Firefox.
Richard.
Richard Cornford wrote:
>>Bart Van der Donck wrote:
if (!v1||!v2) nr = null
Empty strings are valid subjects for comparison so null should not be
returned if either string is empty. This is a case where
type-converting comparison (==) with null is the appropriate test as
both null and undefined equal null, but no string ever would.
I'm surprised that it catches the empty string as well in javascript[*]. For the record,
if (!v1||!v2) nr = null
must become
if (v1 == null || v2 == null) nr = null
[*] IMHO, "if (v1)" should logically read "if v1 is defined", and not
"if v1 isn't empty". Variables that hold an empty value, have been
assigned a defined value, namely the empty one (an empty bottle is also
a bottle, it just happens to be empty). IMVHO. Maybe it's an influence
from other languages.
--
Bart
Bart Van der Donck wrote:
<snip>
[*] IMHO, "if (v1)" should logically read "if v1 is defined", and not
"if v1 isn't empty".
It isn't either, it is "if the value of v1 has true-ness".
(Incidentally, if - v1 - was not defined (as a formal parameter for the
function) the code would error-out)
Variables that hold an empty value, have been
assigned a defined value, namely the empty one (an empty bottle
is also a bottle, it just happens to be empty). IMVHO. Maybe it's an
influence from other languages.
Possibly. In a langue where values will be type-converted it is
important to know what values convert to which values of other types
(and, in the case of objects, the calling of which methods determines
those values).
Richard.
Besides that it returns shuttle value (-1, 0, 1) by default:
var a = 'abcd';
var b = 'efgh';
alert(a.localeCompare(b));
Except that it doesn't return null if one of the two strings is
undefined:
It cannot by definition: it will be either a shuttle value (-1, 0, 1)
or error if the operand is null or not an object. localeCompare imposes
string context on arguments, so implicit (toString) casting is used
before the comparison.
(toString)null == "null"
this way
var v1 = 'null';
var v2 = null;
alert(v1.localeCompare(v2));
gives 0 (equal strings) because "null" and "null" are being compared.
At the same time
var v1 = null;
var v2 = 'null';
alert(v1.localeCompare(v2));
will produce run-time error because indeed you cannot use
localeCompare() method on null;
javascript:
alert('abc'.localeCompare(null)) // says '-1'
thus "lesser than argument" which is right: "abc" string is lesser (in
the string comparison sense) than "null" string;
alert('nulm'.localeCompare(null)) // will give you 1
vbscript:
alert(Strcomp("abc",null)) // says 'null'
Here comes to differences of Nothing, Empty and Null in VB family.
Overall any operation results with imaginary values are "contract
based": they are whatever was decided for a given language. Say there
is nothing in NaN "nature" that would require it be not equal to
anything including itself. It is just a contract behavior. The same
applies to undefined (Nothing) and null (Null).
This is why it is very difficult sometimes to get _exactly_ the same
behavior as in some other language: because one doesn't have control
over contract behavior over imaginary values.
VK wrote:
Bart Van der Donck wrote:
>VK wrote:
>>Besides that it returns shuttle value (-1, 0, 1) by default:
var a = 'abcd';
var b = 'efgh';
alert(a.localeCompare(b));
Except that it doesn't return null if one of the two strings is
undefined:
It cannot by definition: it will be either a shuttle value (-1, 0, 1)
or error if the operand is null or not an object.
Then localeCompare is not a suitable equivalent for Strcomp , which
gets us back at the beginning of this thread. Strcomp always returns
null if any of the two strings (or both) are null.
[...]
vbscript:
alert(Strcomp("abc",null)) // says 'null'
Here comes to differences of Nothing, Empty and Null in VB family.
Overall any operation results with imaginary values are "contract
based": they are whatever was decided for a given language. Say there
is nothing in NaN "nature" that would require it be not equal to
anything including itself. It is just a contract behavior. The same
applies to undefined (Nothing) and null (Null).
This is why it is very difficult sometimes to get _exactly_ the same
behavior as in some other language: because one doesn't have control
over contract behavior over imaginary values.
I don't think that "imaginary values" is a right wording here. But I
share the same experience with such assignments, yes (see only in this
thread the other posts about null/empty/undefined).
--
Bart
Richard Cornford wrote:
Bart Van der Donck wrote:
IMHO, "if (v1)" should logically read "if v1 is defined", and not
"if v1 isn't empty".
It isn't either, it is "if the value of v1 has true-ness".
(Incidentally, if - v1 - was not defined (as a formal parameter for the
function) the code would error-out)
Interesting definition. But it also implies that (defined) emptiness
holds no true-ness. I would rather say that the true-ness of an empty
value lies in the fact that it was computer-scientifically assigned,
defined, known, ... So, in that view, the empty value has equally the
same true-ness as any other assigned value; it's just empty, identical
to a non-empty string, but then empty. It's the assignment that makes
the value of the variable defined and lifts it out of the dark where
nothing was said/known about the value (just the name of the var was
reserved).
The code only errors out if there was no (prior) declaration of the
variable, as in any language that is somewhat strict about its
declarations. An assignment (if any) gives a value to the variable
after its declaration. When a value is assigned (which might be the
empty value, like x = ""), I would say it logically starts holding
true-ness from that very moment.
I can find myself in your view that 'null' or 'undefined' hold no
true-ness in their values.
--
Bart
Bart Van der Donck wrote:
Except that it doesn't return null if one of the two strings is
undefined:
It cannot by definition: it will be either a shuttle value (-1, 0, 1)
or error if the operand is null or not an object.
Then localeCompare is not a suitable equivalent for Strcomp , which
gets us back at the beginning of this thread. Strcomp always returns
null if any of the two strings (or both) are null.
Yes, that is VB(A) choice for comparison of special values. That
suggests to avoid implicit data conversions for "bridging" methods:
thus where the result is obtained in one environment and then sent to
another environment where the result would be possibly different even
with the same arguments. Instead one should use explicit type check
before the operation. This way it is possible to emulate javascript or
VB or whatever needed:
function StrComp(s1, s2) {
if ((typeof s1 == 'undefined') || (typeof s2 == 'undefined')) {
return null;
}
// both null and object reported as "object"
// so two separate branches:
else if ((s1 == null) || (s2 ==null)) {
return null;
}
// I do not remember what does VB return in this case
else if ((typeof s1 == 'object') || (typeof s2 =='object'))
return "?";
}
// I do not remember what does VB return in this case
else if ((typeof s1 == 'function') || (typeof s2 =='function'))
return "?";
}
// I do not remember what does VB return in this case
else if ((typeof s1 == 'boolean') || (typeof s2 =='boolean'))
return "?";
}
else {
return s1.localeCompare(s2);
}
That gets a bit paranoidal of course: as it presumes a user targeted to
crash the program rather than to use it. My position on this aspect was
always "democratic": whoever really applies himself to get a run-time
error - so let him have it. Maybe he he will finally read the fn manual
after that :-)
For the OP case I'm more concerned of null value returned from
anywhere. By the question context I presume it is for some server-side
DB processing which means that all nulls will be eventually transformed
into string values: either for form submission or for ajaxoid. How will
they transformed, will the transformation succeed, what the DB driver
will get and is it ready for say "null" string in client response
meaning Nothing in "its world"?
I don't think that "imaginary values" is a right wording here.
I agree, that may bring to much of "parasite context" of the math. But
the conventional "special values" term is universal up to being
meaningless: it can mean anything anywhere.
Any better terms?
In comp.lang.javascript message <11**********************@s34g2000cwa.go
oglegroups.com>, Fri, 5 Jan 2007 02:39:53, Bart Van der Donck
<ba**@nijlen.composted:
>
function js_Strcomp_binary(v1,v2) {
if (v1>v2) nr = 1
else if (v1==v2) nr = 0
else if (v1<v2) nr = -1
document.write(nr + " <BR>")
}
A) If one has knowledge of the likely results, it may be worth re-
ordering those tests.
B) This should be equivalent, and always does 4 comparisons :
nr = v1>v2 - v1<v2 // if I have the details right.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
Web <URL:http://www.merlyn.demon.co.uk/- FAQqish topics, acronyms & links;
Astro stuff via astron-1.htm, gravity0.htm ; quotings.htm, pascal.htm, etc.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
>>IMHO, "if (v1)" should logically read "if v1 is defined",
and not "if v1 isn't empty".
It isn't either, it is "if the value of v1 has true-ness".
(Incidentally, if - v1 - was not defined (as a formal
parameter for the function) the code would error-out)
Interesting definition.
That is not a definition. It is significant that the subject of your
test is a _value, the value held by the property of the variable object
with the name that corresponds with the formal parameter - v1 -, and
that the value will be type-converted to boolean (which is javascript's
criteria for true-ness).
But it also implies that (defined) emptiness
holds no true-ness.
What is emptiness in this context? If no corresponding argument is
passed to the function call the formal parameters are defaulted to the
undefined value (the single value of the Undefined type, which
type-converts to boolean false).
I would rather say that the true-ness of an empty
value lies in the fact that it was computer-scientifically
assigned, defined, known,
Doesn't that suggest that when a boolean false value is assigned you
would have it considered true?
... So, in that view, the empty value has equally the
same true-ness as any other assigned value;
Including the value boolean false?
it's just empty, identical to a non-empty string, but
then empty.
Are you now not talking of values in general but inserted talking only
of string primitive valves? It would, in principle, be possible for all
string primitives to type-convert to boolean true. but that is not the
way it is in javascript.
It's the assignment that makes
the value of the variable defined
No it is not. Variables are defined when Identifiers are used with the -
var - keyword, used as formal parameters in function declarations and
used as the names of declared functions.
and lifts it out of the dark where nothing was said/known
about the value (just the name of the var was reserved).
If a variable is declared and no other value assigned to it then it
_explicitly_ has the undefined value. Thus any actual assignment makes
no difference to its status as far as 'having a value' goes. This is
particularly obvious when you realise that it is possible to explicitly
assign the undefined value to a variable. If it had the undefined value
prior to the assignment before that assignment, and has the undefined
value following the assignment, in what sense could the assignment be
said to "lifts it out of the dark"?
The code only errors out if there was no (prior) declaration
of the variable,
The 'variable' is a function's formal parameter, so it was 'declared'
(and also has been assigned a value).
as in any language that is somewhat strict about its
declarations.
In that respect javascript is probably one of the least strict languages
going.
An assignment (if any) gives a value to the variable
after its declaration.
In javascript all variables (and formal parameters and declared
functions) are given values during variable instantiation. For a
variable that value is the undefined value, for a formal parameter the
value corresponds with the an argument to the function call, or defaults
to undefined if no argument is received (and the values of declared
functions are references to function objects, unsurprisingly).
When a value is assigned (which might be the
empty value, like x = ""
That is an empty stirring (a string primitive containing no characters),
but it would be a bit hard to call it an "empty value". For a start
there is no concept of an "empty value" in javascript, but an empty
string also exists and has type (it is a string primitive).
>), I would say it logically starts holding
true-ness from that very moment.
True-ness in javascript is the measure of how a value will be handled in
a boolean context. Thus if follows from with of the two boolean values
any other value will be type-converted to if used in a context where
such a type-conversion is implied.
I can find myself in your view that 'null' or 'undefined'
hold no true-ness in their values.
They both type-convert to boolean false if used in a context where such
a type-conversion is implied.
Richard.
Richard Cornford wrote:
Bart Van der Donck wrote:
Richard Cornford wrote:
Bart Van der Donck wrote:
IMHO, "if (v1)" should logically read "if v1 is defined",
and not "if v1 isn't empty".
It isn't either, it is "if the value of v1 has true-ness".
(Incidentally, if - v1 - was not defined (as a formal
parameter for the function) the code would error-out)
Interesting definition.
That is not a definition. It is significant that the subject of your
test is a _value, the value held by the property of the variable object
with the name that corresponds with the formal parameter - v1 -, and
that the value will be type-converted to boolean (which is javascript's
criteria for true-ness).
But it also implies that (defined) emptiness
holds no true-ness.
What is emptiness in this context? If no corresponding argument is
passed to the function call the formal parameters are defaulted to the
undefined value (the single value of the Undefined type, which
type-converts to boolean false).
I would rather say that the true-ness of an empty
value lies in the fact that it was computer-scientifically
assigned, defined, known,
Doesn't that suggest that when a boolean false value is assigned you
would have it considered true?
... So, in that view, the empty value has equally the
same true-ness as any other assigned value;
Including the value boolean false?
it's just empty, identical to a non-empty string, but
then empty.
Are you now not talking of values in general but inserted talking only
of string primitive valves? It would, in principle, be possible for all
string primitives to type-convert to boolean true. but that is not the
way it is in javascript.
It's the assignment that makes
the value of the variable defined
No it is not. Variables are defined when Identifiers are used with the -
var - keyword, used as formal parameters in function declarations and
used as the names of declared functions.
and lifts it out of the dark where nothing was said/known
about the value (just the name of the var was reserved).
If a variable is declared and no other value assigned to it then it
_explicitly_ has the undefined value. Thus any actual assignment makes
no difference to its status as far as 'having a value' goes. This is
particularly obvious when you realise that it is possible to explicitly
assign the undefined value to a variable. If it had the undefined value
prior to the assignment before that assignment, and has the undefined
value following the assignment, in what sense could the assignment be
said to "lifts it out of the dark"?
The code only errors out if there was no (prior) declaration
of the variable,
The 'variable' is a function's formal parameter, so it was 'declared'
(and also has been assigned a value).
as in any language that is somewhat strict about its
declarations.
In that respect javascript is probably one of the least strict languages
going.
An assignment (if any) gives a value to the variable
after its declaration.
In javascript all variables (and formal parameters and declared
functions) are given values during variable instantiation. For a
variable that value is the undefined value, for a formal parameter the
value corresponds with the an argument to the function call, or defaults
to undefined if no argument is received (and the values of declared
functions are references to function objects, unsurprisingly).
When a value is assigned (which might be the
empty value, like x = ""
That is an empty stirring (a string primitive containing no characters),
but it would be a bit hard to call it an "empty value". For a start
there is no concept of an "empty value" in javascript, but an empty
string also exists and has type (it is a string primitive).
), I would say it logically starts holding
true-ness from that very moment.
True-ness in javascript is the measure of how a value will be handled in
a boolean context. Thus if follows from with of the two boolean values
any other value will be type-converted to if used in a context where
such a type-conversion is implied.
I can find myself in your view that 'null' or 'undefined'
hold no true-ness in their values.
They both type-convert to boolean false if used in a context where such
a type-conversion is implied.
I have absolutely no doubt that you are correct about your descriptions
in javascript, but I do doubt if I understand it all :-)
In the traditional theory, each variable must always be undefined
before it can get a value:
(1) reserve the name (declaration)[*]
(2) assign a value, that is, populate bytes with bit patterns
(3) do (2) again as much as you want (or make it undefined again (free
up the memory))
Note that no step is mandatory. Emptiness would traditionally take
place in (2), because it is an explicit act of assigning "" to the
previously declared name. It appears that javascript doesn't follow
this logic. Even "var x = 0; if (x) {alert('ok') }" doesn't show the
alert-window.
Probably I'm thinking in too classic theoretic patterns.
--
Bart
[*] Maybe javascript's "var myvar;" syntax is a far heir of that.
VK wrote:
Bart Van der Donck wrote:
I don't think that "imaginary values" is a right wording here.
I agree, that may bring to much of "parasite context" of the math. But
the conventional "special values" term is universal up to being
meaningless: it can mean anything anywhere.
Any better terms?
I feel something for "the abstract conditionedness of a variable"
(cheers!)
--
Bart
Bart Van der Donck wrote:
<snip>
I have absolutely no doubt that you are correct about your
descriptions in javascript, but I do doubt if I understand
it all :-)
So long as you decline to answer the questions you are asked nobody else
can judge how much you do or don't understand.
In the traditional theory,
Which "traditional theory"?
each variable must always be undefined
before it can get a value:
Wouldn't that depend a great deal of what you men by a "variable" and by
"undefined"? In javascript variables are properties of object (and
properties of objects always have values in javascript) and undefined is
a value (the single value of the Undefined type). There is no sense in
which a javascript variable can exist and not have a value, or be
"undefined" before it has a value.
(1) reserve the name (declaration)[*]
There is no reserving of names in javascript. The properties of objects
that represent variables are created during "variable instantiation".
(2) assign a value, that is, populate bytes with bit patterns
The nature of assigning values in javascript is not certain, nor
important.
(3) do (2) again as much as you want (or make it undefined again
Assigning the undefined value to a property of an object is not distinct
from assigning any other value.
(free up the memory))
In what sense "free up the memory"? The object that has the property
retains its property, and whatever structure links that property with
its value must continue to exist if the value that is linked to is the
undefined value.
Note that no step is mandatory. Emptiness would traditionally
take place in (2), because it is an explicit act of assigning
"" to the previously declared name.
Again you appear to be attributing some wider concept of "emptiness" to
a single value of the string primitive type (the empty string).
It appears that javascript doesn't follow this logic.
Javascript has well specified behaviour that is both consistent and
logical.
Even "var x = 0; if (x) {alert('ok') }" doesn't show the
alert-window.
Why is this relevant? The expression for an - if - statement is
type-converted to boolean in order to decide what it is going to do, and
numeric zero (and NaN) type-convert to boolean false. But why would this
be 'theoretically' unexpected anyway, as in C numeric zero is regarded
as the false value?
Probably I'm thinking in too classic theoretic patterns.
Or maybe you are trying to apply a theory to the wrong structures.
[*] Maybe javascript's "var myvar;" syntax is a far heir of that.
That does not make sense to me.
Richard.
Richard Cornford wrote:
Bart Van der Donck wrote:
each variable must always be undefined
before it can get a value:
Wouldn't that depend a great deal of what you men by a "variable" and by
"undefined"? In javascript variables are properties of object (and
properties of objects always have values in javascript) and undefined is
a value (the single value of the Undefined type). There is no sense in
which a javascript variable can exist and not have a value, or be
"undefined" before it has a value.
The value of a variable is traditionally undefined before it gets a
value (undefined in the literal semantic sense). I'm not sure how that
works on js compile level, but it is a principle of which you can't
step away:
var x = 'abc'
is one instruction, but is short for
var x
x = 'abc'
First create name x and then give it the value 'abc'. As long as 'abc'
is not assigned, x remains undefined, that is, no value is associated
with the declared name at that point. I try to avoid analogies, but
first you need to have a box before you can put something in it (you
need to have something to put 'abc' in). Before you instruct what's in
the box, nothing is said about what's gonna be in it, but the box must
exist already. At that stage, the contents of the box is (still)
undefined.
(1) reserve the name (declaration)[*]
There is no reserving of names in javascript. The properties of objects
that represent variables are created during "variable instantiation".
Reserving a name is a very simple thought. Every javascript variable
has a name. The programmer reserves a name in order to reference to it
at a later time. The official term is "declaration".
(2) assign a value, that is, populate bytes with bit patterns
The nature of assigning values in javascript is not certain, nor
important.
Indeed, that is technically not important as long as your scope is to
stay working inside the javascript engine. But the broader concept is
very important in a sense that every computer works that way.
(3) do (2) again as much as you want (or make it undefined again
Assigning the undefined value to a property of an object is not distinct
from assigning any other value.
(free up the memory))
In what sense "free up the memory"? The object that has the property
retains its property, and whatever structure links that property with
its value must continue to exist if the value that is linked to is the
undefined value.
The memory is traditionally freed once the bytes that hold the value
are made available again for other instructions. Say I have 4 bytes to
my disposal on a 7-bit computer, and do
x = 84
then I take one of the 4 bytes and put 0101010 in it, with 1 as closed
circuit ("on") and 0 as broken circuit ("off"). At that point, x holds
a value and I'm using 25% CPU of the 4 available bytes. When I assign
an empty string to x, I just set it to 0000000, but I'm still using 25%
CPU. Then I make x undefined, thus disconnecting the byte from x. Then
I'm again at 0% CPU (4 bytes available again).
I'm not saying this applies to javascript; but it might be worth
testing it. With very large strings, such memory fluctuations might(!)
be measurable in the browser, but I'm afraid of caching mechanisms +
all kinds of intermediate levels.
[...]
Probably I'm thinking in too classic theoretic patterns.
Or maybe you are trying to apply a theory to the wrong structures.
That is possible.
[*] Maybe javascript's "var myvar;" syntax is a far heir of that.
That does not make sense to me.
When you say "var myvar = 'abc'", you pass 2 commands, namely "var
myvar" and "myvar = 'abc'".
--
Bart
Richard Cornford schreef:
Which "traditional theory"?
Well, the basics. You once said that you could build your own working
computer. I can't do that because I don't have enough electronical and
technic knowledge for it. But I do know how it should work
conceptually.
What would be your plan to build a computer ?
--
Bart
Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
>>each variable must always be undefined
before it can get a value:
Wouldn't that depend a great deal of what you men by a "variable" and by
"undefined"? In javascript variables are properties of object (and
properties of objects always have values in javascript) and undefined is
a value (the single value of the Undefined type). There is no sense in
which a javascript variable can exist and not have a value, or be
"undefined" before it has a value.
The value of a variable is traditionally undefined before it gets a
value (undefined in the literal semantic sense).
Again you are being vague about what you mean by a variable. In C, for
example, a subroutine local variable is a fixed size lump of space on
the stack. It is referenced relative to (offset from) the stack pointer
and while a name might stand in for that reference in the source code
that does not mean the concept and mechanism maps well to javascript.
In javascript the variables are named properties of objects, and all
properties of objects have values.
I'm not sure how that works on js compile level, but it is a principle
of which you can't step away:
But is it a principle that applies at the level that javascript
operates at?
var x = 'abc'
is one instruction, but is short for
var x
x = 'abc'
First create name x and then give it the value 'abc'.
In javascript the "first create name x" stage is "first create a
property of the Variable object and assign it the Undefined value".
As long as 'abc' is not assigned, x remains undefined,
In javascript - x - retains its undefined value.
that is, no value is associated with the declared name at that point.
Which is precisely not the case in javascript, where the general fact
that no property of an object can exist without having a value requires
that variables have values from the moment of their creation.
I try to avoid analogies, but first you need to have a box before
you can put something in it (you
need to have something to put 'abc' in).
But simultaneously, as soon as you have a box it has something in it
(if only a vacuum (as the most 'not containing anything' that a
container can achieved)).
Before you instruct what's in the box, nothing is said about what's
gonna be in it, but the box must exist already. At that stage, the
contents of the box is (still) undefined.
Going back to reserving space on the stack, it would be possible for a
complier to do either of, zeroing all the bits in the reserved space or
leaving it as it is. In both cases the 'variable' would have a 'value'
(in some sense) prior to any explicit assignment of a value.
>>(1) reserve the name (declaration)[*]
There is no reserving of names in javascript. The properties of objects
that represent variables are created during "variable instantiation".
Reserving a name is a very simple thought. Every javascript variable
has a name. The programmer reserves a name in order to reference
to it at a later time. The official term is "declaration".
Maybe, but the mechanism is the creation of a named property of an
object at a particular point in the execution of the code.
>>(2) assign a value, that is, populate bytes with bit patterns
The nature of assigning values in javascript is not certain, nor
important.
Indeed, that is technically not important as long as your scope is to
stay working inside the javascript engine. But the broader concept is
very important in a sense that every computer works that way.
But when you are talking about something that represents a named
property of an object having an internal attribute that links it (in
some way) to a manifestation of a value, and none of: the nature of the
property, the nature of the value, nor the linking between the two, are
specified beyond the behaviour of the resulting system that is to be
achieved, talking of bit patters is meaninglessly specific (even if the
nature of a computer implies that bit patterns must be being set
somewhere).
>>(3) do (2) again as much as you want (or make it undefined again
Assigning the undefined value to a property of an object is not distinct
from assigning any other value.
>>(free up the memory))
In what sense "free up the memory"? The object that has the property
retains its property, and whatever structure links that property with
its value must continue to exist if the value that is linked to is the
undefined value.
The memory is traditionally freed once the bytes that hold the value
are made available again for other instructions.
The implication of the way you worded that was that "free up the
memory" referred to the memory for the variable. But as the variable is
a property of an object the memory needed for the variable itself
cannot be freed until the value of the object that holds the property
is freed.
Say I have 4 bytes to
my disposal on a 7-bit computer, and do
x = 84
then I take one of the 4 bytes and put 0101010 in it, with 1 as closed
circuit ("on") and 0 as broken circuit ("off"). At that point, x holds
a value and I'm using 25% CPU of the 4 available bytes. When I assign
an empty string to x, I just set it to 0000000,
I suspected that your concept of an empty string was a NULL (zero byte
in this context) terminated sequence of bytes (or maybe 16 bit words).
In Java, for example, a string is an object and so 'assigning' even an
empty string may mean writing a 32 bit memory address into your 4
bytes.
but I'm still using 25% CPU. Then I make x undefined, thus disconnecting
the byte from x. Then I'm again at 0% CPU (4 bytes available again).
Again you have a concept that is certainly above machine code (where
bytes being 'available' or 'unavailable' is not externally imposed),
but at the same time a concept that is below (or not sufficient to
explain) Java.
I'm not saying this applies to javascript;
There is very little that can usefully be said about javascript that
can be expressed in terms of writing values into specific memory
locations. Javascript is just too abstracted from that level.
but it might be worth testing it.
Testing what precisely?
With very large strings, such memory fluctuations might(!)
be measurable in the browser,
They are.
but I'm afraid of caching mechanisms +
all kinds of intermediate levels.
>[...]
>>Probably I'm thinking in too classic theoretic patterns.
Or maybe you are trying to apply a theory to the wrong structures.
That is possible.
>>[*] Maybe javascript's "var myvar;" syntax is a far heir of that.
That does not make sense to me.
When you say "var myvar = 'abc'", you pass 2 commands, namely "var
myvar" and "myvar = 'abc'".
I cannot see any way of interpreting your first statement that results
in the second.
Richard.
Bart Van der Donck wrote:
Richard Cornford schreef:
>Which "traditional theory"?
Well, the basics.
In "the basics" there is no such thing as a variable. Variables are
concepts applied to what is going on inside the machine. And what the
machine does is hardly a "theory" either.
You once said that you could build your own working computer.
I can't do that because I don't have enough electronical and
technic knowledge for it.
You don't need to have knowledge to be able to build a computer, only
the ability to acquire the knowledge.
But I do know how it should work conceptually.
The low-level concepts map very directly to specific electronic
circuits.
What would be your plan to build a computer ?
I don't plan to build a computer (beyond buying and assembling
off-the-self parts), it makes no economic sense to attempt that.
Richard Cornford wrote:
Bart Van der Donck wrote:
Richard Cornford wrote:
In javascript the variables are named properties of objects, and all
properties of objects have values.
I'm not sure how that works on js compile level, but it is a principle
of which you can't step away:
But is it a principle that applies at the level that javascript
operates at?
I don't think so.
var x = 'abc'
is one instruction, but is short for
var x
x = 'abc'
First create name x and then give it the value 'abc'.
In javascript the "first create name x" stage is "first create a
property of the Variable object and assign it the Undefined value".
Then you're contradicting yourself. If the undefined value is always
"assigned" first in javascript, then each variable is first undefined
before it gets any other ("new") value.
I try to avoid analogies, but first you need to have a box before
you can put something in it (you
need to have something to put 'abc' in).
But simultaneously, as soon as you have a box it has something in it
(if only a vacuum (as the most 'not containing anything' that a
container can achieved)).
That's why I try to avoid analogies; you can twist them any way you
like to prove some point. It's about the act of the programmer. When
you name the box, you don't say anything about what's in it. After you
named the box, then you name its content. You can only do one thing at
a time.
The memory is traditionally freed once the bytes that hold the value
are made available again for other instructions.
The implication of the way you worded that was that "free up the
memory" referred to the memory for the variable. But as the variable is
a property of an object the memory needed for the variable itself
cannot be freed until the value of the object that holds the property
is freed.
Correct, the variable itself remains available. It are the bytes that
are freed when the _value_ is released; those bytes are no longer
needed and added to the free RAM again.
Say I have 4 bytes to
my disposal on a 7-bit computer, and do
x = 84
then I take one of the 4 bytes and put 0101010 in it, with 1 as closed
circuit ("on") and 0 as broken circuit ("off"). At that point, x holds
a value and I'm using 25% CPU of the 4 available bytes. When I assign
an empty string to x, I just set it to 0000000,
I suspected that your concept of an empty string was a NULL (zero byte
in this context) terminated sequence of bytes (or maybe 16 bit words).
In Java, for example, a string is an object and so 'assigning' even an
empty string may mean writing a 32 bit memory address into your 4
bytes.
The number of bits or bytes doesn't matter; it's only the principle.
Fact is that the empty string must be defined, and the undefined string
must not be defined, otherwise it wouldn't logically be undefined
anymore. The empty string has more in common with the non-empty string
than with Undefined.
but I'm still using 25% CPU. Then I make x undefined, thus disconnecting
the byte from x. Then I'm again at 0% CPU (4 bytes available again).
Again you have a concept that is certainly above machine code (where
bytes being 'available' or 'unavailable' is not externally imposed),
but at the same time a concept that is below (or not sufficient to
explain) Java.
I wouldn't say it specifically applies to this or that, but it applies
to the general principles of RAM. I've had many long conversations in
the past with my dad who worked in a team that fabricated and supported
bespoke computers in the '60-'70. He wrote books about it. Computers
with no screen, no keyboard, just punch cards with bit ranges as ROM
and a couple of halls full of bulbs for the RAM. For me it's clear that
any computer still works using the same principles, only the byte scale
has enormously increased.
I'm not saying this applies to javascript;
There is very little that can usefully be said about javascript that
can be expressed in terms of writing values into specific memory
locations. Javascript is just too abstracted from that level.
Yes.
but it might be worth testing it.
Testing what precisely?
How defined/undefined affects (or doesn't) the machine's CPU.
With very large strings, such memory fluctuations might(!)
be measurable in the browser,
They are.
Then it proves my point.
--
Bart
Andrew Poulos wrote:
I'm writing some ASP using js and I need to do a case sensitive SQL
select. Googling gave me this:
SELECT * FROM User WHERE Strcomp("Blue",[Password],vbBinaryCompare)=0
Strcomp is from vbs. Is there a js equivalent, or some other way to
handle this?
If this is a SQL statement, then whether you need to alter it on the
database you are talking to not on the language you are writing your
ASP pages in.
The statement will be executed by the database, not the ASP engine, so
if your database supports using the StrComp function, use it. You don't
say what database you are connecting to, but I don't know of one that
lets you use javascript in SQL queries.
Bart Van der Donck wrote:
Then you're contradicting yourself. If the undefined value is always
"assigned" first in javascript, then each variable is first undefined
before it gets any other ("new") value.
IMO all languages with "variable pre-declaration" and especially where
undefined value is allowed to be _assigned_ - these languages created a
rather complicated philosophical problem of "two kinds of nothing" :-)
Say:
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
var obj = new Object;
obj.foo = undefined;
window.alert(obj.foo);
window.alert(obj.bar);
}
window.onload = init;
</script>
</head>
<body>
</body>
</html>
Are really obj.foo and obj.bar programmatically hold the same value?
The mind says "no", the result seems implying "yes".
Once I tried to express my doubts about it at
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/60004636376462c>
<http://groups.google.com/group/comp.lang.javascript/msg/7931cf79b142b803>
VK wrote:
Bart Van der Donck wrote:
Then you're contradicting yourself. If the undefined value is always
"assigned" first in javascript, then each variable is first undefined
before it gets any other ("new") value.
IMO all languages with "variable pre-declaration" and especially where
undefined value is allowed to be _assigned_ - these languages created a
rather complicated philosophical problem of "two kinds of nothing" :-)
It are abstractions from a higher level. E.g. ASCII (or any binary
character table) has 0000000 as its official null character, but it is
a defined character (must be). On 1-bit systems you would have two
possibilies, namely 0 or 1 (2^1) while ASCII has 128 (2^7). If you
define a var with 1 byte RAM available on a 1-bit platform, your CPU is
at 100% because you used the byte. If you would leave the variable
undefined, you don't need the byte to store your value and are still at
0%.
You can't *assign* undefined, you just don't store any info for the
value of the variable (or, if it had an already defined value, you
delete what was stored for it).
--
Bart
Bart Van der Donck wrote:
You can't *assign* undefined
This is the whole trick that you _can_ - at least in javascript.
This is what I tried to analize in "undefined vs. undefined" thread
<http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/60004636376462c>
but just was called all names in the book in response. As if the
question was what internal sub executed in this case or in that case.
I don't really care too much - no more as say how does the engine
"know" that NaN == NaN results in false.
But I see a logical contradiction in ability to assign a value "nothing
was assigned" and having an _existing enumerable property_ holding
value "I never was created".
IMO it is just too much of philosophy brought into a programming
language. Or am I wrong? And these results seem logical? :
<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript">
function init() {
var obj = new Object;
obj.foo = undefined;
alert(obj.foo); // undefined
alert(obj.bar); // undefined
alert(obj.foo === obj.bar); // true
alert(obj.hasOwnProperty('foo')); // true
alert(obj.hasOwnProperty('bar')); // false
}
window.onload = init;
</script>
</head>
<body>
</body>
</html>
Bart Van der Donck wrote:
Richard Cornford wrote:
>Bart Van der Donck wrote:
>>Richard Cornford wrote:
<snip>
>> var x = 'abc'
is one instruction, but is short for
var x
x = 'abc'
First create name x and then give it the value 'abc'.
In javascript the "first create name x" stage is "first create a
property of the Variable object and assign it the Undefined value".
Then you're contradicting yourself. If the undefined value is always
"assigned" first in javascript, then each variable is first undefined
before it gets any other ("new") value.
You are speaking of "undefined" as if it was a state, when it is in
reality a value in javascript. Because variables in javascript are
properties of objects there is no state of being not defined, just a
states of an object either having a property or its not having a
property. If an object has a property then that property has a value.
>>I try to avoid analogies, but first you need to have a box before
you can put something in it (you
need to have something to put 'abc' in).
But simultaneously, as soon as you have a box it has something in it
(if only a vacuum (as the most 'not containing anything' that a
container can achieved)).
That's why I try to avoid analogies; you can twist them any way you
like to prove some point.
Or maybe see in an analogy an inconvenient truth.
It's about the act of the programmer. When you name the box,
you don't say anything about what's in it. After you named the
box, then you name its content. You can only do one thing at
a time.
But whatever is considered as "one thing" will depend on the language
being written. The act of creating a new property of an object includes
the assignment of a value to that property. That combination of
internal behaviour is indivisible at the javascript level, so the whole
operation is "one thing".
>>The memory is traditionally freed once the bytes that hold the value
are made available again for other instructions.
The implication of the way you worded that was that "free up the
memory" referred to the memory for the variable. But as the variable is
a property of an object the memory needed for the variable itself
cannot be freed until the value of the object that holds the property
is freed.
Correct, the variable itself remains available. It are the bytes that
are freed when the _value_ is released; those bytes are no longer
needed and added to the free RAM again.
The bytes that are occupied by the value may be freed but assigning the
undefined value (which is the context in which you originally mentioned
memory being freed: "(or make it undefined again (free up the
memory))") has no more than a coincidental relationship to that.
Assigning any value may enable the bytes associated with a previous
value to be freed.
Say I have 4 bytes to
my disposal on a 7-bit computer, and do
>
x = 84
>
then I take one of the 4 bytes and put 0101010 in it, with 1 as closed
circuit ("on") and 0 as broken circuit ("off"). At that point, x holds
a value and I'm using 25% CPU of the 4 available bytes. When I assign
an empty string to x, I just set it to 0000000,
I suspected that your concept of an empty string was a NULL (zero byte
in this context) terminated sequence of bytes (or maybe 16 bit words).
In Java, for example, a string is an object and so 'assigning' even an
empty string may mean writing a 32 bit memory address into your 4
bytes.
The number of bits or bytes doesn't matter; it's only the principle.
Fact is that the empty string must be defined, and the undefined
string must not be defined,
What "undefined string"?
otherwise it wouldn't logically be undefined anymore.
There is no meaning to "undefined string" in javascript.
The empty string has more in common with the non-empty string
than with Undefined.
More in common? It has its type in common, but it shares its absence of
true-ness with undefined, null, NaN, zero, boolean false and some
objects.
>>but I'm still using 25% CPU. Then I make x undefined, thus disconnecting
the byte from x. Then I'm again at 0% CPU (4 bytes available again).
Again you have a concept that is certainly above machine code (where
bytes being 'available' or 'unavailable' is not externally imposed),
but at the same time a concept that is below (or not sufficient to
explain) Java.
I wouldn't say it specifically applies to this or that, but it
applies to the general principles of RAM.
Should the "general principles of RAM" be considered relevant to a
language that never deals in terms of RAM?
But even so you are not dealing with the "general principles of RAM"
when you speak of named variables. Associating names with memory
locations is something that comes into computer languages as a
convenient alternative to using memory addresses directly. It comes in
at a level above machine code, maybe by the level of sophisticated
assembly languages and certainly by the time you get to C and similar
languages. But in the same way as introducing named variables can
abstract away details like memory addresses, javascript has abstracted
away details like numbers of bytes associated with names.
I've had many long conversations in
the past with my dad who worked in a team that fabricated and supported
bespoke computers in the '60-'70. He wrote books about it. Computers
with no screen, no keyboard, just punch cards with bit ranges as ROM
and a couple of halls full of bulbs for the RAM. For me it's clear that
any computer still works using the same principles, only the byte scale
has enormously increased.
Of course computers work the same, and they still execute machine code.
We are programming at a level well above machine code, and with
javascript a level well beyond any interest in the specifics of memory
allocation, and writing bit patterns into memory locations.
>>I'm not saying this applies to javascript;
There is very little that can usefully be said about javascript that
can be expressed in terms of writing values into specific memory
locations. Javascript is just too abstracted from that level.
Yes.
>>but it might be worth testing it.
Testing what precisely?
How defined/undefined affects (or doesn't) the machine's CPU.
Where undefined is a value (the single value of the undefined type)
what is 'defined' and what sense is "defined/undefined" intended to
convey?
>>With very large strings, such memory fluctuations might(!)
be measurable in the browser,
They are.
Then it proves my point.
What point, and how does the ability to create strings sufficiently
large that their presence in memory is easily observed prove it?
Richard.
Bart Van der Donck said the following on 1/8/2007 11:26 AM:
<snip>
You can't *assign* undefined, you just don't store any info for the
value of the variable (or, if it had an already defined value, you
delete what was stored for it).
If you can't "assign" undefined then you should be able to distinguish
between a variable that is truly undefined and one that is set to undefined:
var myVar
var myVar2 = "This is my variable"
myVar2 = undefined
alert('myVar is ' + myVar + '\nmyVar2 is ' + myVar2)
What test can show the difference? If you can't distinguish between
those two - programatically - then it assigns undefined.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
VK wrote:
<snip>
But I see a logical contradiction in ability to assign a value "nothing
was assigned" and having an _existing enumerable property_ holding
value "I never was created".
You may see a logical contradiction but that is because you have
attributed the meanings "nothing was assigned" and "I never was
created" to a value that is the default value for a local variable and
the value returned when an attempt is made to retrieve the value of a
property of an object when the object (and its prototypes) do not have
a property with that name. If you give up your attempt to impose
meaning on the undefined value and start to see it as just another
value then there is no contradiction.
IMO it is just too much of philosophy brought into a programming
language.
Your opinions are, as always, worthless.
Or am I wrong?
Frequently.
And these results seem logical? :
<snip>
It is entirely logical that two operations that result in the same
value should then result in true when places on each side of the
equality operator, and equally logical that creating a property of an
object should result in that object having a property and not assigning
a property should not.
Richard.
Randy Webb wrote:
If you can't "assign" undefined then you should be able to distinguish
between a variable that is truly undefined and one that is set to undefined:
var myVar
var myVar2 = "This is my variable"
myVar2 = undefined
alert('myVar is ' + myVar + '\nmyVar2 is ' + myVar2)
What test can show the difference? If you can't distinguish between
those two - programatically - then it assigns undefined.
What should I expect:
myVar is null
myVar2 is undefined
myVar is
myVar2 is [empty]
myVar is [N/A]
myVar2 is false
or a software error ?
It is "contract based" as V.K. said, which is a good term IMO. It's
heavily language-dependent, but it stands apart from the core nature of
undefined (which has nothing philosophical about it, BTW). It's simple:
undefined = nothing is stored for the variable.
Languages with 5 types of nothings might exist, but those are
higher-level constructions that consume bytes and are created by the
language designers themselves. Obviously that has benefits, and AFAIK
most modern languages use such own creations.
--
Bart
Bart Van der Donck said the following on 1/8/2007 3:00 PM:
Randy Webb wrote:
>If you can't "assign" undefined then you should be able to distinguish
between a variable that is truly undefined and one that is set to undefined:
var myVar
var myVar2 = "This is my variable"
myVar2 = undefined
alert('myVar is ' + myVar + '\nmyVar2 is ' + myVar2)
What test can show the difference? If you can't distinguish between
those two - programatically - then it assigns undefined.
What should I expect:
myVar is null
myVar2 is undefined
myVar is
myVar2 is [empty]
myVar is [N/A]
myVar2 is false
or a software error ?
Then you should change your expectations :) The reality is that they are
both undefined and - to date - I have not seen code that can distinguish
between them.
It is "contract based" as V.K. said, which is a good term IMO.
Huh? There is nothing "contract based" about undefined.
It's heavily language-dependent, but it stands apart from the core nature of
undefined (which has nothing philosophical about it, BTW). It's simple:
undefined = nothing is stored for the variable.
If you want a "nothing" and want to be able to distinguish it from
undefined then set it to null instead. Then you can programatically tell
the difference between an undefined variable and one you cleared yourself.
--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/index.html
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Bart Van der Donck wrote:
Randy Webb wrote:
>If you can't "assign" undefined then you should be able to
distinguish between a variable that is truly undefined and
one that is set to undefined:
var myVar
var myVar2 = "This is my variable"
myVar2 = undefined
alert('myVar is ' + myVar + '\nmyVar2 is ' + myVar2)
What test can show the difference? If you can't distinguish
between those two - programatically - then it assigns undefined.
What should I expect:
That is a strange question. What you should expect is, inevitably, what
the specification for the language says you should get (which is also
what reality delivers).
myVar is null
Did anyone ever assign null to that variable? You know that the system
assigned the undefined value when it created the property of the
Variable object, and as no other value has been assigned to replace the
default value the value of that variable is still the undefined value.
myVar2 is undefined
Inevitably, as that was the value that was assigned (though it is
possible to assign a different value to the 'undefined' property of the
global object and so change the value assigned with - myVar2 =
undefined -, though obviously that is not a particularly good idea).
myVar is
myVar2 is [empty]
myVar is [N/A]
myVar2 is false
You still don't seem to be grasping the fact that all variables will
always have a value, as a consequence of their being created as
properties of objects. Properties of objects can either exist or not
exist, but when they exist they have values.
or a software error ?
It is "contract based" as V.K. said, which is a good term IMO.
Please try to take the time to read some of VK's posts before giving him
any credence. After supposedly spending 10 years 'writing' javascript he
is still producing code as self-evidently poor as:-
<URL: http://groups.google.com/group/comp....244b525c8d374c
>
- and remains incapable of joining up the logic of the situation to the
extent that he could see what is wrong with that code (indeed he usually
cannot see it when it is pointed out to him).
It's heavily language-dependent,
We only have one language to discuss here, and in that language the
behaviour is well-specified, consistently implemented and completely
predictable.
but it stands apart from the core nature of undefined
(which has nothing philosophical about it, BTW). It's
simple: undefined = nothing is stored for the variable.
You are talking about a concept attached to a word. That concept is not
present in javascript, instead there is a value with the name
'undefined'.
Languages with 5 types of nothings might exist, but
those are higher-level constructions that consume bytes
and are created by the language designers themselves. Obviously
that has benefits, and AFAIK most modern languages use such own
creations.
This obsession with bytes will leave you going round in circles.
Richard.
In comp.lang.javascript message <11**********************@38g2000cwa.goo
glegroups.com>, Mon, 8 Jan 2007 08:26:53, Bart Van der Donck
<ba**@nijlen.composted:
>You can't *assign* undefined, you just don't store any info for the
value of the variable (or, if it had an already defined value, you
delete what was stored for it).
var U, X = 9
X = U
X // now = undefined
It is a flaw in the definition of javascript that the initial state of a
variable takes a definite value *called *undefined**. In javascript,
undefined is well-defined. It should have been called something which
does not occur in ordinary technical language - owt / wossat / oooerrr
etc. Perhaps "incertus", on the assumption that few nowadays discuss
javascript in Latin.
In a language such as (Borland) Pascal, where all possible bit-patterns
are equally legal for most types, "undefined" safely means "could be any
legitimate value. In the case of floats, it would be possible to set
aside one of the NaNs for the purpose.
But in javascript, where an object has a variable type, it is necessary
to have the object store not only the bits representing its value but
also a representation of its type. The latter can easily values of null
and undefined, as well as Boolean, Number, etc.
--
(c) John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v6.05 MIME.
<URL:http://www.merlyn.demon.co.uk/TP/BP/Delphi/&c., FAQqy topics & links;
<URL:http://www.merlyn.demon.co.uk/clpb-faq.txt RAH Prins : c.l.p.b mFAQ;
<URL:ftp://garbo.uwasa.fi/pc/link/tsfaqp.zipTimo Salmi's Turbo Pascal FAQ. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: John |
last post by:
Is there an equivalent of COM on Linux that I can get through Python.
My need is to have some sort of language independent component
framework. I can think of CORBA but I have to have a server...
|
by: Michael Foord |
last post by:
Please pardon my ignorance on this one - but I'm not certain how the
sign bt is treated in python bitwise operators. I've trying to convert
a javascript DES encryption routine into python.
...
|
by: Robert Dodier |
last post by:
Hello,
Here's a thought that I'm sure has already occurred to
someone else, I just can't find any record of it yet.
An XML document is just a more verbose and clumsy representation
of an...
|
by: Vannela |
last post by:
Is there any equivalent control in .NET for the Power
builder DataWindow control?
I am explaining the Datawindow architecture to some extent.
Power Builder DataWindow Control has got different...
|
by: steven scaife |
last post by:
Ok i need to compare 2 values from my array but strComp no matter what
returns 1 even though my comparison values are the same
if i do this
str1 = "wed"
str2 = "wed"
strComp(str1, str2)...
|
by: Tim Conner |
last post by:
Hi,
I am an ex-delphi programmer, and I having a real hard time with the
following simple code (example ):
Which is the equivalent to the following code ?
var
chars : PChar;
sBack, s :...
|
by: karch |
last post by:
How would this C# contruct be represented in C++/CLI? Or is it even
possible?
PolicyLevel level = (enumerator->Current) as PolicyLevel;
Thanks,
Karch
|
by: Alan Silver |
last post by:
Hello,
I'm converting some old VB6 code to use with ASP.NET and have come
unstuck with the Asc() function. This was used in the old VB6 code to
convert a character to its ASCII numeric...
|
by: grid |
last post by:
Hi,
I have a certain situation where a particular piece of code works on a
particular compiler but fails on another proprietary compiler.It seems
to have been fixed but I just want to confirm if...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The...
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
| |
