How a delete a object from DOM ?

[Richard Cornford]

You can't win an arguement with the largest troll of
this group.

... confuse everything someone writes in tons of words.

Confused by words? Does that mean you resolve your script design debates
with fisticuffs?

... . He is a rather amateur troll as trolls goes.

That would be "as trolls go".

... . For instance, one of the most extreme trolls around ...
... brags about going through 2 or more remailers.

<snip>

Are you implying that there is a relationship between non-amateur
trolling and attempted anonymity - justme33?

Richard.

 

[darwinist]

Richard Cornford wrote:
[...]

Now show me the search term for the back-end that, when it is not found,
verifies that the Identifier/function definition is _not_ machine
generated? Say the back-end is (100%) Java, what do you search for? What
if it is N tier written in a number of languages?

You're right it would only work in a particular context, that of a
single, self-contained, client-engine script, that was not altered by
any automatic process. Perhaps I don't have enough experience to know
why you would want to use javascript outside of such a domain. For
other features there are better languages, as far as I know. Perhaps
you could enlighten me.

<snip> [...]

Functions should not try to fit the language they are written
in,

Which has no relationship to giving functions names that say something
about what they do.

but rather the application they are creating. That is
their "natural" meaning.

That sounds impressive, but doesn't appear to mean anything (that is, it
sounds like marketing-speak).

The purpose and function of an application defines a context that you
can see even before the actual code is written. Short and common words
will therefore have a more specific meaning in the application, than in
just any program written in the same language.

Function names should say enough to state what the function is doing at
the point where the function is called, and without reference to the
actual function definition.


I did not see a counter argument, only an assertion of a relationship
along the lines of; "If you can express the initial prototype more
quickly" then ' there _is_ a relationship between an ability to optimise
for speed and the use of any particular naming convention'. Where the
latter does not follow from the former unless there was demonstration
that a "particular naming convention" (rather than naming conventions in
general) directly resulted in an ability to "express the initial
prototype more quickly" (whatever that is intended to mean).

Well an application, for the writer, is a series of statements. The
first proofs of concept for all the features is a prototype, and if
your naming convention is economical, you can express (the statements
of) those proofs more quickly and in less space.

You have not demonstrated that any "particular naming convention" (or
that your particular naming convention) has any benefits (presumably
resulting in the quicker expression of prototypes) that cannot be found
in other naming conventions.




A call to the same function is a call to the same function whatever the
name of that function is.


Sufficient that it becomes unnecessary to cross-reference the function
call with the function definition, certainly whenever the function
definition is expected to be some distance form the call.


If a context is beyond 'an understanding of the native language of the
programmer' (or at least the language that (s)he used when writing the
Identifiers, as that sometimes is not their native language) then the
meaning is not 'inherent'.


Conventions provide meaning beyond what is inherent. For a programmer
common, well known/recognised conventions may provide meaning that is
approaching 'inherent' in its significance; and expectation that
something will mean something specific.



The choice between camel-case and using underscores to separate words in
Identifiers either arbitrary or the subject of convention (possibly
formalised). I am told that when reading most of the time it is the
recognition of patterns in the symbols on a page that allows
understanding, rather than the parsing of sequences of letters. In that
way a camel-case Identifier can be seen as the same on each occasion it
is referenced and its meaning only derived from the sequence of
characters it contains on the first reference.

If camel-case really were an issue we would already be habitually using
underscores to separate words in Identifiers.

That's not my issue, my issue is how much each "word" is doing.
Javascript method calls are a single action, but often three or four
words mashed together. Using the context of a specific function or
application, that action could be given a simpler, more readable label.

But given that HTTP 1.1 requires user agents and servers to support zip
compression/decompression downloadability is (or could/should be)
related to the post-compression nature of the source, and repetition is
what compresses best. The practical impact of may occurrences of the
same 10-20 characters of source text is likely to be negligible.

Good point, it's only for literary economy then. For readers and
writers.

Or; the implied necessity to integrate the existing code with the
javascript code needed for any real application makes it particularly
important to maximise the readability of the code, especially for the
experienced javascript programmers who are the only people who should
sensibly be employed in writing a web application sufficiently complex
as to require an in-browser windowing GUI.

Most simple web applications, such as email and message board programs
could benefit from a basic windowing system, it's doesn't require
anything heavy or complicated, which was the point of my example
application.

 

[Richard Cornford]

Richard Cornford wrote:

You're right it would only work in a particular context,
that of a single, self-contained, client-engine script,
that was not altered by any automatic process.

Which still required verifying that there is no back-end or
pre-processing involved.

Perhaps I don't have enough experience to know
why you would want to use javascript outside of
such a domain.

The vast majority of web applications are a combinations of server-side
and client-side code, and even pure client-side (HTML + javascript)
projects may be created with a content management system or
pre-processor. So in practice there is usually plenty of potential for
any given piece of javascript to be machine generated by other software.

For other features there are better languages, as far
as I know. Perhaps you could enlighten me.

Not unless you can explain what you are talking about more clearly.

The purpose and function of an application defines a context
that you can see even before the actual code is written.
OK.

Short and common words will therefore have a more
specific meaning in the application, than
in just any program written in the same language.

That would probably depend on the size and scope of the application.
Your 'make', for example, can only have specific meaning in an
application where only one thing (or one type of thing) can be made.
Once there are numerous things that can be made (or deleted) 'make' (or
'del') would need to be qualified by what it was that was being made (or
deleted).

Well an application, for the writer, is a series of statements.
The first proofs of concept for all the features is a prototype,
and if your naming convention is economical, you can express
(the statements of) those proofs more quickly and in less space.

And the relationship with an ability to optimise for speed is?

That still stands.

That's not my issue, my issue is how much each "word" is
doing. Javascript method calls are a single action,

Even a single action must have something to act upon.

but often three or four words mashed together. Using the
context of a specific function or application, that action
could be given a simpler, more readable label.

Certainly a function contained within a limited scope, where its use
must be limited to code in the same scope (and physical separation could
not be too great) might use a general name that would be ambiguous in
other contexts.

But then, have we been talking about a context restricted use of a
naming convention? In this very thread you proposed the function names -
$ - and - $del - without even knowing the context of the application
being written.

Most simple web applications, such as email and message
board programs could benefit from a basic windowing system,
it's doesn't require anything heavy or complicated, which was
the point of my example application.

Neither requires an in-browser windowing system, so introducing a
dependency on limited browser support and client-side scripting is
acting to restrict the general viability of the end result for no
apparent reason other than that it can be done.

Richard.