optimistx said:
You have done a considerable amount of work to answer my post and
I appreciate that.
I feel your tone in the answer interesting. In case you might
be interested in my feelings
Why would anyone be interested in your feelings? Reality is not
modified by how you feel about it. That can only impact on how you
perceive reality, and won't impact on anyone else.
pls go ahead. In other case you can STOP HERE.
Keep working at it and you might achieve a situation where nobody
bothers with your questions at all.
First of all, feelings, human relations, politeness, friendliness
are not part of javascript and therefore might be off topic here.
Obviously, so why do you waste so many words on that subject here.
Being off topic might be another reason to STOP HERE, and
preferably put my writings to a killfile now.
As an exercise in human interactions, I would like to express
in in my own words (vs copying your words),
Fine, so long as you provide definitions for any non-javascript
standard jargon you elect to use. Otherwise you will likely end up
saying nothing.
what I understood you to probably say. I might comment and
answer later but not in this entry.
I hear you telling me that instead of "composite variables"
I should have written " 'references' to objects".
Or provided a clear definition of what you mean by "composite
variables" in this context.
I feel that you are very annoyed about my unprofessional usage
of words.
Not annoyed, just pointing out that when there is no meaning in what
you re saying you are effectively saying nothing, which can be done
with far fewer words.
You say that the topic of my entry is not real,
Without stating the definition of the term in relation to things that
do exist in javascript there are no "composite variable" in
javascript, and so they are not real.
it is in the imaginative world only.
You are not sure what I meant,
I am sure that prototypes (objects in general) don't have variables
and so that writing to a "prototype variable" has no meaning in
itself..
and guessed one possibility
I am perceiving the wide spectrum of possibilities. Picking one is the
only way of going forward. Assuming that one possibility would not
necessarily be valid, so questioning your meaning and waiting for
clarification makes most sense.
expressing that in your words. If the guess were true,
you wished that I had been as expertlike in
using words as you are,
and used the same expression as you.
Not just me, but employing the terminology that has objective meaning
when applied to this subject.
You assume that possibly I do not understand what the expression
var SES = SES || {} is doing.
I don't care whether you understand it or not. It certainly is utterly
superfluous to your question and so is more likely to get in the way
of understanding than to achieve anything else.
You ask me, why I added the above to the example.
And you are making it clear that you are not going to answer that
question.
You do not consider it useful.
The only impact removing from the example would have would be to
simplify its presentation and ease its interpretation.
You consider it unnecessary and difficult to
understand, not simple.
I consider it superfluous.
You think that due to the above I do not understand the example.
Knowing what is relevant and what is superfluous is an indicator of
understanding.
If I had not used the above, I might have understood.
Maybe, but understanding would have suggested not including anything
superfluous in your question.
SES.A = function () {
this.prim = 'this.primitive';
this.obj = {key1: 'key1 value in obj'};
}
SES.B = function () {
}
SES.doit = function () {
var a1, b1, b2;
a1 = new SES.A();
SES.B.prototype = a1;
b1 = new SES.B();
b2 = new SES.B();
b1.obj.key1 = 'b1.obj.key1';
^^^^^^^^
This is writing to a property of an object that is 'referred to'
by a property of the object that is the [[Prototype]] of - b1 -.
With other words, the last statement above is storing
a value to a memory location,
That is nearly meaningless in context. The odds are that an assignment
in javascript results in values being sorted in memory locations in
the implementation, or in the VM that runs the implementation, or at
least somewhere, but that has little of value to say about
javascript's behaviour.
Consider, for example, the assignment of a numeric primitive value to
a property of on object. In javascript terms that is probably the
whole story (minus getters/setters and ReadOnly attributes and the
like). For the implementation the value assigned has a type (it is a
numeric primitives) and it has a value (a 64 bit IEEE double precision
floating point value). From the property of the object it is necessary
to be able to recover both the type and the value, which means that
either the 'property' has to know the type and the value, or the
'property' has to know where it can get at the numeric primitive and
the numeric primitive knows both its type and value. So if assignment
does involve writing a value to a memory location then that action is
certainly not going to be anything as simple and direct as writhing
the 64 bit IEEE double precision floating point value to some memory
location.
Also remember that javascript has been implemented in Java (Rhino) and
JavaScript(tm) (Narcissus), and neither of those languages have any
means of directly addressing memory locations.
whose reference is in a property of the prototype of b1.
You reword what my code says.
Yes, because your issues appears to be not appreciating that writing a
value to a property of an object that is not a [[Prototype]] of - b1 -
will not result in that value being inherited.
You say essentially the same as I say,
I didn't notice you saying anything, the mass of words not
withstanding.
using your own, more exact words.
You feel that I should not use in these discussions my own
words
Not without defining them. Consider the terms; "the call object", "the
calling object" and "the default object". All of which appear in
writings about javascript, but in contexts that imply such a range of
meanings that the meaning for each become mutually exclusive. Unless
someone actually states what thy mean by, for example, "the default
object" then they will end up saying nothing. On the other hand, a
term like "Variable object" has such clear, specific and objective
meaning that a statement about a "Variable object" is very likely to
be only one a true statement or a false statement.
and general purpose English. I should use
exactly the words which you use or ECMAScript-262
define.
You are asking, how I know that primitives are copied to a
function.
That was the question, and if you tried answering it you might realise
that you cannot tell.
I understand you infering, that if a primitive is
a function argument, it either is not copied to the
function, or in some situations it is, some others it
is not:
No, I was trying to highlight the fact that you cannot tell.
var a = 1;
function f(arg){arg++}
f(a);
alert(a) // if copy, alert shows 1, if not copy, alert shows 2
This comment, for example, implies the notion that primitive values
could be modified, which is not the case in javascript. In practice
the - arg++ - replaces the value of the 'arg' property of the
function's execution context's Variable object with another primitive
value that is the result of adding a numeric value of one to the
original value. This could never have any impact on the numeric
primitive that was previously assigned to 'a' property of the global
object.
Recalling that primitive values have both 'type' and a 'value'.
I understand you saying that if
var a = 1;
a = 2;
then the primitive variable value a is not changed from 1 to 2.
The primitive value that has a 'type' of number and a value that is
the IEEE double precision representation of 1 is not modified. Instead
another primitive value that has a 'type' of number and a value that
is the IEEE double precision representation of 2 is assigned to the -
a - variable.
Further, if a is a property of object o with primitive value,
var o.a = 3;
o.a = 4;
then o.a is not changed from 3 to 4
The value of the 'a' property of - o - is changed from one numeric
primitive to a different numeric primitive.
You do not understand my question.
The question doesn't mean anything. It is just a string of jargon.
You recommend (me) to increase
(my) understanding. Then my programs behave as I want.
In the event of knowing how you want your programs to behave,
understanding how the language works will considerably contribute
toward achieving that behaviour.
You say no, prototypes is not a fad, or it might be. You
consider the question unclear and give therefore an unclear
answer.
One can use less memory with prototypes and use less cpu-time.
You assume that I start dismissing prototypes
You are the one questioning whether prototypes are a "fad".
therefore that I do not understand them. You understand
them. My behaviour is SILLY.
Acquire understanding somewhere, somehow, and do not bother
me with SILLY questions.
<snip>
Yes, questions like "Or is this whole idea of prototypes a fad ... "
are silly and pointless in this context. Javascript has prototype
inheritance and it really doesn't matter whether that is a god thing
or a bad thing. They are the things that they are, they work the way
they work, and they are not going away any time soon, so either you
understand them or you don't ever understand javascript. And if you
don't understand them then there are a mass of better, more useful,
questions that could be asked instead.
