Equivalent of Strcomp

[Richard Cornford]

Richard Cornford schreef:


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.

 

[Bart Van der Donck]

In javascript the variables are named properties of objects, and all
properties of objects have values.


But is it a principle that applies at the level that javascript
operates at?

I don't think so.

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.

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

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.

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.

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.


Testing what precisely?

How defined/undefined affects (or doesn't) the machine's CPU.

They are.

Then it proves my point.

 

[news]

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.

 

[VK]

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>

 

[Bart Van der Donck]

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

 

[VK]

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>

 

[Richard Cornford]

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.

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

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.

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.

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.

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?

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.

 

[Randy Webb]

Bart Van der Donck said the following on 1/8/2007 11:26 AM:

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.

 

[Richard Cornford]

VK wrote:

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.

 

[Bart Van der Donck]

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.

 

[Randy Webb]

Bart Van der Donck said the following on 1/8/2007 3:00 PM:

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.

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]
glegroups.com>, Mon, 8 Jan 2007 08:26:53, Bart Van der Donck

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.

 

[Richard Cornford]

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.lang.javascript/msg/2a244b525c8d374c
- 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.