Re: How a delete a object from DOM ?

Richard Cornford wrote:
[...]
It would only be a matter of a few seconds if there was
someone about to ask, otherwise reading the documentation
would take at leas some minutes (assuming that someone had
documented the convention, and verifying that the Identifier
was not machine generated from the code could be very time
consuming (as if it was machine generated you would eventually
discover where and how but you could not be certain that it
never was until everything had been examined).

Geez: search-> "function $del("-> "all files in project"->"find";

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.

e) you can then optimise for speed in any areas that
are script-heavy.

There is no relationship between an ability to optimise
for speed and the use of any particular naming convention.

If you can express the initial prototype more quickly and
clearly then yes, there is.

There is no relationship between an ability to optimise for
speed and the use of any particular naming convention.

I gave a counter-argument, you just repeated yourself.

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.


<snip>
Your equation of clarity with an absolute naming
convention,

I made no such equation. You are the one proposing absolute
naming conventions here. I am proposing names that convey
inherent meaning.

That can only be taken so far, before you are repeating
yourself unnecessarily to anyone who has spent more than
ten minutes with your code.

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

Of course function names should have inherent meaning. What
kind, how much,

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.

and in what context should that meaning be "inherent"?

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

That is the point of contention.

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.

<snip>
The code is closer to english and no matter how well you
get to know any computer language, english will be clearer,
especially when you've been away from the project for a
while or someone else takes over some of it.

Leading $ symbols are "nearer to English"?

No but single words with punctuation between are clearer than
javascript method calls.

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.

<snip>
So will long and complicated statements, which are
inevitable if you stick as close as possible to the
native javascript/dom methods when writing your applicatoin.


Well? Replacing re-occurring blocks of code with parameterised
function call is normal and sensible. I would question the
reason for wrapping code in a function when that function itself
only contains one line of code.

To save 10 - 20 bytes per call.
<snip>

Ten to twenty bytes of what? For each function call the
javascript engine must create its representation of the
execution context (to hold the current scope), create and
initialise ... .

Many javascript applications are installed across the world
over networks and updated often. Downloadability is part of
a web-pages usability.

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.

The main purpose of my desktop was to show how easily and
concisely this functionality can be achieved. Any customised
content or style would need to be on top of this and so it's
even more important to keep down the size of the code.

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.

.

Relevant Pages

  • Re: Essay on PID Motor control
    ... > go overboard on the math, I do think that a few simple, well-chosen ... I think it is a great convention because I know, ... is a zero terminated string, pVar is a pointer to a var, etc. ... any naming convention for that matter does take time to get used too, ...
    (comp.robotics.misc)
  • Re: Naming Conventions dot net/csharp
    ... private variables and methods you can use your own convention. ... > Naming standards for everything throughout an Assembly. ... or your company standardises on a naming convention for private stuff, ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Language mavens: Is there a programming with "if then else ENDIF" syntax?
    ... _list would lead to confusion with builtins, ... But I'm not sure what naming convention you used. ... arbitrary to me, but whatever it is, it clashes with built-ins, which is ...
    (comp.lang.python)
  • Re: Coding Conventions for C#
    ... > According to that naming convention, a parameter should be be named like ... > by the amount of code that goesinto creating an app. ... > Even though the hungarian convention is supposedly no longer considered good ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: How a delete a object from DOM ?
    ... machine generated means the experienced javascript programmer has to ask ... And it takes a fool to introduce a project specific style convention ... programmers. ... What is common practice? ...
    (comp.lang.javascript)
Loading