The importance of having a head, as it is said in books dealing with the evolution of the species, is paralleled only by the importance of having a name.
A name is the threshold of personal identity, finally attained. It is an acknowledgement of importance before the conscience of another being.
None the less, animals need not name each other, but they recognize each other as well.
So a name isn't but a crown put on top of a set of properties, the flag that encompasses a domain and a set of characteristics whose possession is acknowledged as granted to those who carry the name. It's a shorthand to power.
 
Names are meant to be unique, in theory. If Adam called the cattle cattle and the fowl fowl, he can't call the one by the name of the other any longer.
Having a name means to be counted in inside the tribe: for the arrays of the daemons are numberless accordingly to the Bible, whereas as even Origen teaches us in his "Homelies on Numbers", only the holy and the upright are counted in and accounted for: Numbers.

Gn:18:24:
«If there be fifty just in the city, shall they perish withal? and wilt thou not spare that place for the sake of the fifty just, if they be therein?»

Commandments, they are 10; senses, they are 5: gimme a man or a woman (the Bible says: a just) that can understand with all his/her 5 senses the meaning of all of the 10 commandments: 5*10=50.
Because some understand with the eye, sticking to the apparent and missing the Spirit; others listen with the ears, as hearsay, and forget; others have to put the finger in the wound, or won't believe the Invisible ("visibilium et i n v i s i b i l i u m"); others need the smell of the incense, and would not appreciate without authority; others need to be nourished to understand.
But when asked what he desired most to have, Solomon, the symbol of the wiser among the wisest, answered: lebh shomea (from: The Lost Ark, by Giuseppe Cognetti): a hearth that perceives correctly (which beauty many translations I now notice completely miss: Kings book 1, chapter 3 verse 11: "wisdom to discern").
Thus a proper name is but a pendant of a proper perception. As such a name is never arbitrary.
 
Why a proper perception is needed? Because ethics is not concerned with what, but with why: a bird that kills a prey is not evil: its nature forces him to survive that way; but a man that kills a man because of greed is evil.
None the less, if you attain 50, the perfection of all senses in perception, your sin is forgiven.
And, by the way, the main source of distorted perception is when the subjective interferes with the objective.
Note: not when the sentiment interferes, for the sentiment is wanted: it is feeling, so it perceives; it is the lack of discrimination what causes evil: disordered perception that overwhelms you is as much un appropriate and detrimental as lack of feelings is in order to see the outline of the names of things.

The user wrote the following code, that trivial: <form name="contact"> <input name="submit" type="submit" value="Send"> <input name="cancel" type="reset" value="Cancel"> </form> Then the user discovers that when calling by a script the following instruction:
document.contact.submit()
he gets an error message claiming that submit is not a function, whereas we all know it is a built in javaScript function.
The user gets crazy 'bout it.
Eventually he changes the names of the form tags (name=) and all goes back to work smoothly. But the user still wonders why before it didn't.
 
Firstly, forget that Objects exist. Nothing like that ever existed: Object is just a... name.
And such name has been bestowed to codes that under a strictly informatic point of view have never been "Objects" but just branched data, or structured data: an "Object" isn't but a nucleus of statements that has been structured so that all of its statements belong to the same grouping.
Call it group, call it structure, call it tree: but please for the children's sake stop calling it an Object or a "Class" as if it would have been endowed with a special breathing of its own.
It is just structured digital data, with nothing more prestigious than any other structured data like a normal Array, and calling it "an Object" just introduces the mystification that puts you under the ominous spell you're dealing with something different than mere trivial traditional mainstream digital structured heaps of statements/data: you're not!
 
As such, all structured data aren't but names given to sections of digital statements:
class IM_just_A_NAME_DUDE{}
 
Inside there you can put further names for further statement sets. They're still just set of quite normal digital statements that you've just appended a name to!
class IM_just_A_NAME_DUDE{
   function IM_JUST_ANOTHER_NAME{}
 aPropertyName="hallo world"
}
 
Now you have but a set of digital statements that are nested in within each other and aren't but plain text with names appended. You must get persuaded it is nothing more than this.
The best way to keep in mind they are just Ramificated nodes of Names as Strings of Text is by getting the habit of referring to their branching by using the associative Array procedures: referring an element by a set of square brackets with in within the brackets the mere name given to the element in between quotes (it isn't but a String!): IM_just_A_NAME_DUDE["IM_JUST_ANOTHER_NAME"] That points to the function statements inserted in within the grouping referred at by the name:
IM_just_A_NAME_DUDE
 
Whether you're aware of this or not, whenever you deal with a script (a javaScript in our case) you already have a consistent set of such names assigned by default before your intervention: they are called keywords or reserved words: document is a keyword, whereas perhaps you would have referred to the same set of statements pointing to the contents of a file by, say, file: but you have some of these decisions that have been taken before your arrival, so you just have to grin and bear it: some names are already assigned.
 
Now, the reason the so called "classes" have been invented, is basically to save bandwidth when coding: you describe a template (class) of a set of digital statements and whenever you have to arrange things so that an element on a page (in our javaScript environment we're mostly concerned with pages you see...) has to behave in the way described by that set of statements encompassed by the name given to that class, you just activate a new instance of such class instead of retyping the whole of the same code again and again (at times thousands of lines!); assigning then different values to be held by the given set of structured data, will account for the possible differences in the details of the behaviour of the page element.
 
Now, forms on a webpage are exactly drawn by a common template, and each form isn't but an instance of such common template: the fact you don't perceive the existence of the template because it is concealed within the inner workings of the javaScript interpreter, doesn't mean the template doesn't exists.
So, it is exactly the existance of this template that allows you to define more forms in the same page being sure all have the same basic characteristics (can be submitted, have an action, have buttons, have text fields).
This template, endows each instance of the form you include in a page by the tag <form> with a set of pre-defined names pointing to further branches in the structure.
So you have something similar to: class Form{ elements=function(){blah blah}; action=""; method="get"; submit=function(){blah blah}; reset=function(){blah blah}; onclick=function(){blah blah}; onfocus=function(){blah blah}; //... ... ... button=new Button();//calls in an external class named Button? textarea=new Textarea();//calls in an external class named Textarea? } So each form includes a set of names, that could be addressed -as we previously said- by the associative array procedure as well:
form["elements"]
The template as such can never be accessed or affected. None the less, each time you insert a new set of <form></form> tags, you make the equivalent than calling this:
insert new Form()
Namely you draw a new instance from the template.
This new instance has a full fledged set of names exactly identical to those in the template, but that this time affect only this specific instance and that in this instance can be accessed and affected: that is, you cannot access or affect the abstraction (the template) but you can access the embodiment (the instance).
So if you have given the name "contact" to your form, you can quite validly call:

<body>
<form name="contact"> blah blah </form>

<script>
alert(
document["contact"]["submit"]
)
</script>
</body>

If you copy that and you execute it, the alert would return:

function submit() { [native code] }

You see: your function named "contact" has drawn from an original and native template a set of names for a set of built in statements of code, in this case the code that is encompassed and locked to the assigned name: submit.
 
Whenever you initialize a new form by html tags, and consequently you draw a new instance of the Form "class" and you engrave it in the page, you can later populate this newly generated instance with further names pointing to further sets of digital statements defined by yourself: example:

<body>
<form name="contact"> bla bla </form>

<script>

document["contact"]["foo"]=function(){
alert("Hallo Folks")
}
//now a NEW PROPERTY EXISTS in document["contact"]:
//document["contact"]["foo"]; it was DEFINED BY YOURSELF!
//prove it:

document["contact"]["foo"](); //TRIGGERS THE ALERT!
//it was the SAME as: document.contact.foo()

</script>
</body>

What would happen if you were so unmindful to call an object defined by yourself with a name which was already assigned to something else (keep in mind javaScript is case sensitive)? Example:

<body>
<form name="contact"> blah blah </form>

<script>

document["contact"]["submit"]=function(){
alert("Hallo Folks")
}
//now a PROPERTY EXISTS in document["contact"]:
//document["contact"]["submit"]; it was DEFINED BY YOURSELF!
//prove it:

document["contact"]["submit"](); //TRIGGERS THE ALERT!
//it was the SAME as: document.contact.submit()
//but what happened to the ORIGINAl behaviour submit()?
//it has got OVERWRITTEN BY YOURS!

</script>
</body>

If you do such a thing, the last introduced name prevails on its previous definitions or assignments, and therefore if in the given instance of the form (the given form, as I repeat: you cannot affect the Template) you introduced a set of digital statements appending them to the form and calling them with a name that by chance was already existing in the Form Template, this instance of the form would get such name replaced by your code, and thus the original codex pointed by such name would no longer be accessible, for you've set that name to point to something completely different (your own defined codex). Well, the mystery is explained: in fact whenever you assign a name to an element of a form too, you introduce in the set of property names belonging to this instance of the Form template a new name: and if this latest name coincides with a name already existing, it would overwrite the original. Thus if in a form you include a form element named just... submit, the name submit given to the form would replace the name submit of the native code and thus such native code won't be accessed anymore (and you won't be able to submit your form any longer...). Evidence:

<body>

<form name="contact">

<input 
name="submit" just OVERWRITTEN original submit method
type="text" 
value="put text here!">

</form>

<script>
		alert(
		document["contact"]["submit"]
		)
/*that won't return NATIVE CODE  any more! But: object (the page textfield!)*/
//and, even more significantly:
		alert(
		document["contact"]["submit"].value
		)
//would return:... PUT TEXT HERE!
</script>

</body>

The last thing you may be wondering is how comes that the assignment to the name property of a from element can affect and overwrite the default name spaces of a form instance, whereas if you make analogous assignments to, say, the type property of a form element such overwriting doesn't occur: that is, why:
<input name="submit"> overwrites but:
<input type="submit"> does not?
 
Because the name property of a form tag delivers its name to the whole form, but not the rest of its tag properties: an input tag must deliver the name property to the form otherwise the form won't be able to handle and recognize such named an input as one among its own user defined range of pertinent objects: that is, if the name assigned to a form tag won't enter also the space name of the form properties within the form the tag belongs to, it wouldn't be possible to address any element by its name:
document.formName.elementName
Thus the name becomes a shared element between the input and the form: it is the link between them!.
 
So as far as the name property of a tag is affected, this gets shared with the form, but as far as the other properties are affected, such as type, they cannot interfere with the form because they're exclusive of the tag with no need whatsoever to share them:
document.formName.elementName.type
is a property of elementName, not of formName as you may see: thus if you assign to the type the name "submit" this could in no way interfere with formName, because it belongs not to it but to elementName.
Only the name property gets shared, and as such a variation in it has a double edged effect: changes the name of the input, and changes also a name inside the set of properties defined for this form; and this can overwrite native stuff.
 
Type is another, different thing, and it belongs to the element, which is a distinct item from the form despite it is a child of the form as well since it is nested. Thus being a child doesn't mean the object cannot retain its own identity, and even produce an active feedback on the parent element.
 
You and your father are different entities: your father can still call you by your name: it is still you, and he retains a right to call you by your name: but he doesn't retain any special right to withhold a wide set of specific elements proper to yourself like the type, which as such belong to you and to you only regardless of any inheritance.
 
A good Object Oriented Programming derives by a happy solution of the Oedipus Complex, namely from a clear perception of the linkage.