By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
459,405 Members | 1,357 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 459,405 IT Pros & Developers. It's quick & easy.

Javascript Best Practices Document v1.0

P: n/a
http://www.JavascriptToolbox.com/bestpractices/

I started writing this up as a guide for some people who were looking for
general tips on how to do things the 'right way' with Javascript. Their code
was littered with document.all and eval, for example, and I wanted to create
a practical list of best practices that they could easily put to use.

The above URL is version 1.0 (draft) that resulted. IMO, it is not a
replacement for the FAQ, but a more practical guide for fixing some of the
problems that commonly get pushed into web sites.

Any comments?

PS: Ignore the formatting. It's ugly, for now ;)

PPS: I know that there are exceptions to many of the 'best practices' in
very specific situations when approached by an experienced author, but the
goal of this document is to help the average joe developer fix common
problems and write more acceptable code.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Oct 11 '05
Share this Question
Share on Google+
136 Replies


P: n/a

"Randy Webb" wrote:
Thomas 'PointedEars' Lahn said the following on 10/29/2005 6:41 AM:
This is of course a matter of (personal) philosophy. Mine and
it seems also Richard's is:

"Give a man a fish; you have fed him for today.
Teach a man to fish; and you have fed him for a lifetime."


True but Richards, at times, seems to expand to:
"Give a man a fish; you have fed him for today. Make a man a
commercial fisherman; and you have fed him for a lifetime."


That might be it, or I may be pointing out that there would be a
difference between teaching someone to fish with a hook and line, a net
and with dynamite.

Richard.
Oct 30 '05 #101

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
If someone expresses a desire to understand javascript
I am likely to propose that they learn javascript.
The point you missed: Not everyone wants to understand
javascript. Some just want to take advantage of its
features by implementing packaged solutions.


And the point you miss is that the wants and desired of an individual
are not, in isolation, sufficient to justify action on the part of those
individuals. There is a reason that responsible parents do not let their
children say up all night whenever they want to, and do not let them eat
what they want to eat whenever they want to eat it. And as adults, when
we are expected to apply some personal judgement in assessing the wisdom
of acting on our every whim, we all live under a legal system that makes
it very clear that some wants should never be gratified.

If people don't want to learn to understand javascript that is fine, all
they have to do is never use javascript. But the desire to use
javascript without an understanding of how to use it has real, harmful
consequences. In a non-professional context those consequences don't
mater too much, people should be allowed to do harm to themselves (only)
if that is their desire, but when someone is being paid (a fee or wages)
there clients/employers have a right to expect them to know enough not
to be doing harm by their actions.

I encountered yet another example of this on Friday when a friend of one
of my mangers, who happens to run his own small business, asked me to
look at his recently re-designed web site and see of there was any
apparent reason why it had dropped out of the Google listings following
the re-design. Apparently he had notices a significant drop in enquires
(in a business where a few enquires now means the possibility of no work
in a couple of months time) and in investigating possible reasons he had
noticed the change in Google's placing of the site, and that the drop in
enquires and change in google rankings had followed the site re-design.
None of the content of the site had changed a word, just the way in
which it was presented. A task undertaken by a 'professional' web
designer in exchange for a fee.

I looked at the HTML of his home page, and I looked for links into the
rest of the site. There were none. Instead all of the navigation into
the rest of the site was handled by a javascript menu, with the link
URLs defined in an external JS file. It wasn't even a complex
(drop-down, expanding tree, or similar) menu, just rollover effects. It
could have been done entirely with CSS that even IE would understand an
act upon. But no, a combination of wanting to use javascript without
understanding it and the availability of a pre-built menu script were
enough to allow a 'professional' web designer to take a fee for
significantly harming the future viability of her client, risking the
livelihoods of its employees and forcing it pay a similar fee to someone
else to rectify the situation.

I can understand that individuals may not want to take time and effort
to learn particular technical skills, but I cannot see that as
justifying their going on to perpetrate unskilled applications of the
technologies when the consequences are so predictably harmful.
If the idea of spending many hours learning a programming
language is not practical then the fact that it takes
many hours learning any programming language would man that
there are no programmers.


Your statement is as ridiculous


Not as a response to the statement of yours that it followed. You have
edited out its context (and failed, again, to mark that eddit).
as saying that if it weren't practical for people to learn
to repair their own cars, we wouldn't have auto mechanics.
It's not, in fact, practical for many people. I didn't say
it was not practical for anyone.
Your statement was: "The idea of spending many hours learning a
programming language is not at all practical". That is a general
statement without qualification, and as the consequences of its being
true contradict the empirical evidence it is therefor a false statement.
A large part of the point of the exercise is not to address
as many specific cases as possible, but instead to only
implement the component versions for the specific cases
actually encountered, as and when the are encountered.
Avoiding writing specific code until it is needed, and still
creating easily re-useable code, is one of the characteristics
that makes the strategy efficient.


I disagree.

You are solving the specific case each time a new one
comes up.


Not each time, only the fist time. Fortunately specific cases do tend to
reoccur on a regular bases. While some of the possible permutations of
the general case may be extremely uncommon.
I find it to be more challenging, rewarding, and beneficial
to try to solve the general case (as much as possible) and
then apply it to the specific case at hand.
You are fixating on the problems of general algorithms. Which is not
that surprising as general algorithms are a prerequisite of general
libraries. The general problem that I am interested in is finding an
optimum code authoring strategy. And one of the issues that I need to
address in achieving that is avoiding the problem of the general
algorithm. The general algorithm may be ultimately re-useable, if it can
actually be achieved, but it is often big, often slow, and sometimes an
impossibility.

In looking at strategies the observation that code is ultimately never
used in a general context allows the issues to be avoided entirely. But
obviously re-writing everything for each specific context is not
efficient, as it eliminates the potential for code-reuse.

My answer to the problem is to build application specific code on top of
re-usable low level components that provide an interface to the
browsers. Such that those low-level components can be specifically
appropriate to the context of their use, but if the context changes they
can be replaced with a different component proving the same public
interface.

The challenge in that is designing an interface that provides the
necessarily information/actions while allowing the component that
provides it to have various diverse implementations.

The result is code that is:-

1. Re-usable, taking advantage of the fact that specific contexts do
reoccur in web development (particularly the common ones).
2. Fast in executing, because it is not trying to take account of
possibilities that are not present in the particular context.
3. Reliable, because it is possible to rigorously test such components
in isolation and so be confident that they do work as designed in the
context for which they were designed.
4. Easily maintained, because changes in their context can be
accommodated by swapping one reliable and well-tested component with
another providing the same interface and so not impact upon any of the
higher level code at all.
5. Small, because excluding consideration of the conditions that do not
apply to a specific context allows the corresponding code to be omitted.

While the general algorithm might be re-usable, and if it is a full and
correct algorithm it may also never need maintaining, but in attempting
to be general it cannot help but be slower and bigger. And rigorously
testing a truly general algorithm means exposing it to all of the
possible permutations, including the ones that are so unlikely that they
may never be encountered in a real context. Indeed, writing re-usable
context specific components as and when needed may mean never having to
tackle the more obscure possible permutations at all, while the quest
for the general algorithm pre-supposes the handling of all such
permutations form the outset.
If someone asks, "how do I find the position of my object
on the page?" and you supply the simplest solution which
will work on their example page, you may not be helping as
much as you could.
I wouldn't respond to such a question by supplying anything.

Such a question would be a joke if it was intended to be a specification
for a browser scripting task, certainly a long way short of something
that could be analysed, designed and implemented.

If the question was asked on this newsgroup it would probably be best
answered with a request for more information. But might instead warrant
a discussion of the properties, object and methods available to provide
position and dimension information, and the factors influencing their
application in determining the absolute position of an element.

It is perhaps significant that you have decided to pick on this
particular task, as you appear to be getting increasingly bitter about
the fact that nobody seems willing to help you write a general
position/dimension reporting algorithm. Though I must remind you that
when you asked the specific question I did tell you that un-resolvable
contradictions made the general position/dimension reporting algorithm
an impossibility. As it happens I have changed my mind about that
because I have seen a was of resolving those apparent contradictions,
but the resulting algorithm is so convoluted that I suspect it would
have to apply a couple of thousand lines of code to each
node/node-ancestor in the DOM. The result might work, but would be too
slow to be practically used in any of the contexts where I have been
interested in knowing elements position/dimensions.

Consider some of the factors involved in the general position/dimension
reporting algorithm:

There is the CSS 'display' property, which may have any of the values;
inline | block | list-item | run-in | compact | marker | table |
inline-table | table-row-group | table-header-group | table-footer-group
| table-row | table-column-group | table-column | table-cell |
table-caption | none | inherit, and any value may be assigned to any
element at any time. So whenever the display value may influence the
calculation of positions and dimensions (which it does) then the
influence needs to be determined on a node by node bases and taken into
account. Of course the odds (even the rational) of someone switching the
display property of an element from 'table-footer-group' to 'compact' in
any real context are extremely low. But that is one of the problems with
the genial algorithm, you have to account for all of the possibilities
or it is not truly general.

Then there is CSS 'position', which may be static | relative | absolute
| fixed, and can also be changed at any point (at least on some
browsers). Combine that with the fact that any element can be moved in
the DOM from one point to almost any other and it is quite clear that
the general algorithm needs to re-calculate the positions and offsets
for each node that it takes into account when calculating positions for
each individual position it calculates.

And the above CSS properties may be mixed with; border-collapse,
border-spacing, empty-cells, float, list-style-position,
list-style-type, marker-offset, table-layout, list-style to produce more
permutations of layout behaviour, and that is without considering the
influence of borders, padding, margins and scrolling.

Summing up the offsetTop/Left of the offsetParents works in the simplest
case, but CSS can have a huge influence on where those offsets are taken
form and the general algorithm needs to be taking that into account.

Abandoning the concept of a general algorithm and working with only the
factors pertinent to an actual context massively reduces the problem,
and allows for possible optimisations in the code that is used. And
doing so with a low level component providing an interface to the
position/dimension information retains the flexibility of the
theoretical general algorithm by allowing the component to be swapped
with one tailored to any other specific context.

Consider, for example, a real context where it is known that no page
elements will have borders, that the HTML and BODY elements will have
zero padding and margins, that all tables will have -
border-collapse:collapse; - and - border-spacing:0; -, that no display
style will be switched from its default to anything but none, and back
again, that no position property will be switched at all, that no
overflow property will be set to auto or scroll and that no element will
be moved in the DOM. The remaining permutations are so reduced that not
only can an appropriate algorithm be easily implemented but it can also
be heavily optimised to minimise the work done to aquifer each
position/dimension.

It may sound like a very restrictive context, but it does apply to a
great many real web sites, and slightly different permutations of
restrictions cover huge numbers of real web sites. All without ever
having to tackle the general problem of accounting for the influence of
all possible permutations.
Tomorrow, if they introduce scrollable areas into their page,
Tomorrow? Real web sites are not radically re-designed at the drop of a
hat. If a design is such that scrollable areas are a possibility then
that is part of the context from the outset, and they may or may not
appear on any specific page. If the design suggests (or the designer
states) that no page divisions will be scrollable then the introduction
of such arias implies a significant re-design. And a significant
re-design is likely to break any pre-existing javascript anyway.
change their layout with CSS, or put some browsers into
standards mode, your solution may break.
It won't break, it will require that the pertinent component be swapped
for one suited to the new context. And given that this happens in the
context of a significant site re-design that is not particularly
unexpected, as whoever deployed the original component understood its
limitations and know the re-design will take it outside its specified
boundaries.
And the person will once again have no idea to fix it,
But If they understood why and how they were using the code in the first
place they would understand how to fix it.
because you gave them a very limited-scope solution which
can't be applied in varied situations.
And what did you supply them with? You gave them code that you clamed
was a general solution (or, more realistically, a 'partial general
solution' (nonsense though such a claim would be)) and it will also
break in the face of particular site re-design changes. And you pretty
much grantee that the individual using your script will not know how to
fix it.
Instead, you can solve the general case which also happens to
solve their specific example.
If you can solve the general case. And assuming that the solution is
viable. I tend to find that when I want to know the position and
dimensions of an element I want that information about a group of
element more frequently than 15 times a second (preferably 24 times).
The bulky, slow, general position/dimension algorithm just cannot
deliver the required performance, because it has to take into account so
much, and do so for each node/node-ancestor.
Then, when their page changes, they don't need to change their
code, because the general solution already considers it correctly.
Again, if you can solve the general case.
The few extra k of
code which is not actually executed in each case is easily
offset by the fact that you don't need to go back and re-visit
the code to solve the new specific case, or change the code
used every time your layout changes.
The stuff that doesn't ever get executed is only the parts that can be
seen to apply to other browsers and the alternatives to things that can
be decided just once and cannot be dynamically changed (such as
standards/quirks mode). The rest, everything that can be influenced by
dynamic manipulation, needs to be re-calculated continuously. The truly
general algorithm must account for all of the possibilities or it is not
general.
The obvious fact to me is that most people prefer the
approach taken by me and many others.
Most people wouldn't have a clue hat you were talking about if you asked
them. This is a question that is only even of interest to a minority of
web developers. So that is a minority of a minority of people.
You may not, and that's fine, because obviously you have
the time and talent to do things your own way.
The question of time is a significant motivating factor in seeking an
effective and efficient strategy. As I have already said, my time is
allocated to projects for the next year, each one with a deadline, and
each followed by another with its own deadline.

<snip> ... . I don't hear anyone saying, "Thank god I didn't
implement a packaged solution, but instead spent the last
3 months learning and experimenting with javascript so I
could build up my own low-level function library and solve
the specific requirement that I had 3 months ago!"
That is not something you are likely to hear. But you don't have to read
this group for long to see many examples of people who have been using
pre-packed libraries to give the impression that they could use
javascript and have now been asked to do something that they cannot find
pre-packaged and are asking for help meeting a deadline that they could
have met on their own if they had bothered to lean javascript for
themselves in the meanwhile.
Compare it to some every-day examples:
Browser scripting is not directly comparable with everyday examples of
anything. Browser scripting isn't even comparable with any other types
of programming. Remove the downloading issue, the variation in execution
environments and the relatively slow execution and discuss a language
that has its resources on the local computer, provides a known
environment and is compiled into machine code and the library concept
goes form being a dubious idea to being the most sensible strategy
available.

But even so, how many real world examples are there of people providing
professional technical and design services without their accepting a
need to understand what they are doing? And how many clients of such
professionals would not have exactly that same expectation?
When you buy a new TV, do you learn electronics from scratch
and build your own to only have the features you want? Or do
you buy one that costs a little more and has more than you
need, but gives you a TV right away and gives you options in
the future?
The person who needs to learn how to build a television set is
television set designer.
When you want a new computer, do you research and buy all
the parts separately and spend time assembling them to get
the maximum possible performance? <snip>

Yes of course. Computer parts are really easy to assemble, something to
do with the parts being designed to be interchangeable by implementing
common interface standards.
When you choose an OS, do you build it from scratch and make
it consist of the fewest possible features that you need to
use, in order to optimize performance? Or do you use a packaged
solution with lots more functionality than you'll ever need,
which uses more disk space and CPU, but makes your life easier
and more convenient?
Some and some. I learnt the Windows batch installation process years ago
so when I install it I only install the components I want and have my
personal user preferences in place form the fist boot-up.
Using a pre-packaged, generalized solution to a given problem
is not lazy or a cop-out as you seem to suggest.
But selling your services as a creator of javascript using web sites
without understanding what your are doing is as irresponsible as I
suggest. And it is the pre-packaged 'solutions' that make doing so
possible.
It's a realistic approach to take when you consider all the
factors involved and decide that building your own from scratch
just isn't advantageous.
Can someone who is ignorant of the technology they are using take all
the factors involved into account?
Why you object to it as a concept continues to baffle me.
It fails to deliver what it promises. It has directly harmful side
effects. There are better approaches. Why would I stop objecting?
I can only assume that you either have no understanding of the
real problems and priorities faced by many developers in the
world,
I certainly have no understanding of a web developer/designer who would
make an informed decision to do significant harm to their clients.
or that you must dismiss generalized solutions in order to
justify your own work to yourself.


The only people I need to justify my work to are my employers. And given
the pay rise they offered me last week I have to conclude that they are
more than happy with it and definitely don't want me to even think about
working for anyone else.
It is ironic that you should describe others as "Elitist
assholes" when your characterisation of "the average web
developer" as incapable of achieving even your level of
understanding of the subject carries the implication that
you consider yourself their innate superior.


Incorrect.

Many people can achieve the level of understanding that I,
you, or anyone else has. I understand that many people
don't _want_ to, and many people don't have _time_ to, and
many people have higher priorities. I'm not superior, and
they aren't stupid. They just aren't focused on the same
things as I am, and I see no reason to tell them that they
need to be (as you do).


So having characterised the "average web developer" as a headless
chickens incapable of making informed decisions about the actions they
take, you are now admitting that there is no problem with a lack of
ability.

So we a left with people not learning javascript because they don't want
to. Which is not a problem, they can still practice the skills they do
have. But not wanting to learn a skill is not a reason for attempting to
practice it anyway, and no excuse for the harm that is the likely
consequence of doing so.

Richard.
Oct 30 '05 #102

P: n/a
On Thu, 27 Oct 2005 23:09:14 -0500, in comp.lang.javascript , "Matt
Kruse" <ne********@mattkruse.com> in <dj*********@news4.newsguy.com>
wrote:

[snip]
You are solving the specific case each time a new one comes up. I find it to
be more challenging, rewarding, and beneficial to try to solve the general
case (as much as possible) and then apply it to the specific case at hand.


This is great as long as you know the appropriate general case. And
that you can only learn by doing some specific cases and making some
guesses about the future. I frequently find that I have improperly
generalized some routine, that I guess wrong about what I was going to
need.
[snip]

--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"
Oct 31 '05 #103

P: n/a
Richard Cornford wrote:
Indeed, writing
re-usable context specific components as and when needed may mean
never having to tackle the more obscure possible permutations at all,
while the quest for the general algorithm pre-supposes the handling
of all such permutations form the outset.
You imply that a "general" solution must consider every possible
permutation. I disagree.
In fact, a "general" solution need only be tested in the situations that it
claims to cover, which is no more work than testing your separate
components.
"how do I find the position of my object
on the page?"

It is perhaps significant that you have decided to pick on this
particular task, as you appear to be getting increasingly bitter about
the fact that nobody seems willing to help you write a general
position/dimension reporting algorithm.


I'm not bitter in the least. I think it's an interesting and challenging
topic, and one that would benefit from discussion.
Consider some of the factors involved in the general
position/dimension reporting algorithm:
<snip long list of 'issues'>
I'm not sure that much of what you listed even applies. When the browser
lays out the page, it calculates the offsets for the element, given its
position and display type. The programmer doesn't need to evaluate all these
permutations, since the browser already does it.
See my test page at:
http://www.mattkruse.com/javascript/...sitionTest.php

It covers some of your conditions, and seems to do so quite easily. I plan
to add more test cases when I have time to see where it begins to fail.
Although, I feel that most typical test cases are probably already covered
by the code in the above page.

I believe that you are greatly over-exaggerating the effort required to
develop a general solution that covers a wide variety of situations, since
you've probably never looked into it. If a situation is encountered that
isn't covered, support for it can be added. Just as you would manually write
code to cover the situation in your 'swappable components' model. Except
with the general solution, you're just adding conditions rather than
re-writing a function.
But that is one of the problems with the genial algorithm, you
have to account for all of the possibilities or it is not truly
general.
General != Exhaustive
Although the closer you can get to exhaustive, the better.
Tomorrow, if they introduce scrollable areas into their page,

Tomorrow? Real web sites are not radically re-designed at the drop of
a hat.


I am entertained by the fact that you have defined what a 'real' web site is
:)

I know plenty of 'real' web sites that change their design regularly, or
even allow the end-users to alter the design. I know 'real' web sites that
are just wrappers for content that users or customers supply. If they wish
to provide javascript functionality, it needs to be able to handle a variety
of situations, without knowing in advance what the situation will be.
I tend to find that when I want to know the position and
dimensions of an element I want that information about a group of
element more frequently than 15 times a second (preferably 24 times).
I've never had such a requirement. *shrugs*
I imagine if you have a demand for this kind of performance, you might find
the general solution to be slow, and investigate ways to speed it up or
start from scratch.
But even so, how many real world examples are there of people
providing professional technical and design services without their
accepting a need to understand what they are doing?


Many. And many are quite successful.
But that doesn't really matter in this discussion.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Oct 31 '05 #104

P: n/a
VK wrote:
I was following this discussion and wondering: what in the name these
fisherman's talks have to do with the announced topic?
Don't even try to bother to understand it. Most certainly it will go over
your head.
My wild guess would be [...]


Of course, this is the only level of thinking you appear to be capable of.
PointedEars
Oct 31 '05 #105

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
Indeed, writing re-usable context specific components as and
when needed may mean never having to tackle the more obscure
possible permutations at all, while the quest for the general
algorithm pre-supposes the handling of all such permutations
form the outset.
You imply that a "general" solution must consider every
possible permutation.


If I only implied it then I am not being sufficiently clear. I
unequivocally assert that a general algorithm must consider every
possible permutation, or is it not a general algorithm.
I disagree.
In fact, a "general" solution need only be tested in the
situations that it claims to cover,
What is the claim being made when you attach the label "general" to an
algorithm?

If I write:-

function getYPosition(elRef){
return 27;
}

- and state that it only covers the situation when the element is 27
pixels from the top of the page I can then label it a "general"
algorithm and expect to be taken seriously?

No amount of weasel-words will render that extremely context-specific
(and 100% successful and accurate within its stated context) function
"general".
which is no more work than testing your
separate components.
A restricted context algorithm is not harder to test than a restricted
context algorithm. But in your previous post you were asking me what
happened when someone changed the context so that it fell outside of the
restrictions. To which I replied that because the restrictions on the
context in which the component would operate were known up-front they
know that they have to change the component. While the pretence in
labelling restricted context algorithm as "general" will leave them
expecting it to cope, and probably unsure of what exactly it was that
stated to fail following the change of context.
"how do I find the position of my object
on the page?"

It is perhaps significant that you have decided to pick on this
particular task, as you appear to be getting increasingly bitter
about the fact that nobody seems willing to help you write a
general position/dimension reporting algorithm.


I'm not bitter in the least.


Then why all the whining and name-calling?
I think it's an interesting and challenging topic,
and one that would benefit from discussion.
It has been discussed. You weren't very interested in listening to what
was said in that discussion so there doesn't seem much point in
repeating it.
Consider some of the factors involved in the general
position/dimension reporting algorithm:
<snip long list of 'issues'>


I'm not sure that much of what you listed even applies.


That is precisely that attitude that makes further discussions of the
subject with you pointless. You are offered the clues and instead of
doing some work to find out why they are significant you would rather
dismiss their relevance entirely.
When the browser lays out the page, it calculates the offsets
for the element, given its position and display type.
And when a browser calculates an offset where is it an offset from?
The programmer doesn't need to evaluate all these
permutations, since the browser already does it.
To calculate the absolute position of an element the programmer needs to
understand the significance of the various values the browser provides.
See my test page at:
http://www.mattkruse.com/javascript/...sitionTest.php
LOL, you are not even trying.
It covers some of your conditions,
My conditions?
and seems to do so quite easily.
Superficial testing often results in inaccurate perceptions. I saved
your HTML locally, added one style attribute, setting one CSS property,
to one element on the page and suddenly your little marker is half a
page away from where it was supposed to be. Frankly, I am already using
components that I would never dream of describing as "general" that
already handle more possible (and actually likely) permutations that
your code would.
I plan to add more test cases when I have time to see
where it begins to fail.
Good, because the more time you send only looking at cases where it
works the more misplaced confidence you risk placing in a very
inadequate algorithm.
Although, I feel that most typical test cases are probably
already covered by the code in the above page.
I have been maintaining all along that the majority of real contexts can
be accommodated by relatively simple algorithms. Indeed, you are
attempting to allow for scrolling elements within a page, and so doing
extra work. I think that the majority of real contexts don't have
scrollable elements within a page so in most cases that extra code
doesn't have to be included/executed either.
I believe that you are greatly over-exaggerating the effort
required to develop a general solution that covers a wide
variety of situations, since you've probably never looked
into it.
Excellent reasoning. You know that I write DHTML that reacts in real
time to the re-flowing of documents so you conclude that I know nothing
about what it takes to determine the position and dimensions of elements
within a document.
If a situation is encountered that isn't covered, support for
it can be added.
And added, and added, and added, and added, until you actually are
covering all of the possible permutations, and have a chunk of code so
big and so slow that it becomes self evident why this entire strategy
was a bad idea form the outset.
Just as you would manually write code to cover the situation
in your 'swappable components' model.
Except that having observed that all conditions cannot apply to any
specific context at the same time it is clear that when a new condition
is encountered the need to add code to accommodate it is likely to
coincide with the possibility of removing/excluding code that does not
apply. So while the collection of components is likely to expand the
individual components do not have to become ever more complex.
Except with the general solution, you're just adding
conditions rather than re-writing a function.
If you ever get around to trying you will find plenty of need for
re-writing, but even if you could just add code that isn't necessarily a
good thing as it means that the totality must always get larger and
slower in the process.
But that is one of the problems with the genial algorithm, you
have to account for all of the possibilities or it is not truly
general.


General != Exhaustive
Although the closer you can get to exhaustive, the better.


By which you mean; if totally exhaustive then totally general.

Which is true. The question is what perverse use of English allows the
use of the label "general" with an algorithm that is not exhaustive.
This is more of your "partial solution" nonsense. But we are dealing
with computer programming here; the world of relentless, deterministic,
mechanical logic. Computers are not impressed by rhetoric.
Tomorrow, if they introduce scrollable areas into their page,

Tomorrow? Real web sites are not radically re-designed at the
drop of a hat.


I am entertained by the fact that you have defined what a 'real'
web site is :)


And the definition of 'real' that I stated was?
I know plenty of 'real' web sites that change their design
regularly,
You do appear to associate with some staggeringly inept web developers.
Thinking here seems to be that re-designing a web site is so expensive
and time consuming that doing so at intervals of less than six months
would be pouring money down the drain.
or even allow the end-users to alter the design.
Alter the design or alter their presentation? A design that allows the
user to alter their presentation is still a known design, and so
provides a known (if broad) context.
I know 'real' web sites that are just wrappers for content that
users or customers supply.
A design that allows the user to supply the content is still a known
design. And whatever wraps will constrain whatever is being wrapped, to
some degree or another.
If they wish to provide javascript functionality, it needs
to be able to handle a variety of situations, without
knowing in advance what the situation will be.
Don't be silly. Allowing a remote user total control over a web site is
a recipe for disaster.
I tend to find that when I want to know the position and
dimensions of an element I want that information about a
group of element more frequently than 15 times a second
(preferably 24 times).


I've never had such a requirement. *shrugs*


Oh you have had that requirement, you have just ducked it with talk of
'partial solutions' and things that are 'good enough in most
circumstances'. If you ever get to the point of being able to write GUI
components that are as potentially fluid as the pages that they may find
themselves used on you will rapidly see more value in fast algorithms
than general ones.
I imagine if you have a demand for this kind of performance,
you might find the general solution to be slow, and
investigate ways to speed it up or start from scratch.


What I investigate is strategies that deliver the results.
But even so, how many real world examples are there of people
providing professional technical and design services without their
accepting a need to understand what they are doing?


Many. And many are quite successful.
But that doesn't really matter in this discussion.


You edited out (again without marking the edit) my second, and more
important question, which was; "And how many clients of such
professionals would not have exactly that same expectation?". Clients do
expect individuals who purport to offer professional technical and
design services to have an understanding of what they are doing. And
that is not an unreasonable expectation, even if disappointed by some
(maybe, in your world, many) unscrupulous individuals.

Richard.
Oct 31 '05 #106

P: n/a
Lee
John G Harris said:

In article <vq**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writes
JRS: In article <Sz**************@jgharris.demon.co.uk>, dated Fri, 14
Oct 2005 19:41:23, seen in news:comp.lang.javascript, John G Harris
<jo**@nospam.demon.co.uk> posted :
In article <TF**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writes
JRS: In article <3r************@uni-berlin.de>, dated Wed, 12 Oct 2005
19:30:42, seen in news:comp.lang.javascript, Gérard Talbot
<ne***********@gtalbot.org> posted :

<snip>
>IMO, tricks based on + and -0 can not be the best recommendable way to
>convert a string to a number. parseInt or parseFloat should be used instead.

Then you are wrong; and sentences should start with a capital letter.
<snip>

Not funny. This newsgroup is read by beginners; we mustn't trick them
into writing ParseInt (with a capital P).


Agreed. The solution is to recast the sentence so that parseInt does
not come first. Putting "Function " before it is generally
satisfactory.


What a very silly thing to say.


It seems very reasonable to those of us who care about readability.
mW powers your torch.
MW melts scrap metal.


Neither makes a good start for a sentence.


What is the symbol for milliwatts?


It is "mW".

However, readability is much more important in the context of
documentation than in a dialog like that example.

I would have said:

The parseInt() or parseFloat() function should be used instead.
(except of course, that it should not).

Oct 31 '05 #107

P: n/a
Richard Cornford wrote:
I unequivocally assert that a general algorithm must consider every
possible permutation, or is it not a general algorithm.
Semantic games bore me. Stop playing them.
To me, you are describing an "exhaustive solution".
To me, a "general solution" is one which is written so as to not be specific
to a single situation, but can be applied to a number of different
situations (but not necessarily all).

You understand what I mean. If you would like to use different words to
describe what you know I am talking about, let me know what your preferred
words are. Then maybe you can stop arguing about words and start discuss the
concepts behind them.
When the browser lays out the page, it calculates the offsets
for the element, given its position and display type.

And when a browser calculates an offset where is it an offset from?


Depends on the browser, of course. And the page contents.
See my test page at:
http://www.mattkruse.com/javascript/...sitionTest.php
It covers some of your conditions,

My conditions?


Yes, the long list of things that you said could be applied to a given page
to make a general position-finding function impossible. Things like adding
borders, margins, etc. My example page has test cases for some of those
things, and no extra consideration was needed to handle them correctly.
I saved
your HTML locally, added one style attribute, setting one CSS
property, to one element on the page and suddenly your little marker
is half a page away from where it was supposed to be.
What exactly was it that you changed?
Oh, wait, let me guess... "I'm not going to tell you, because you don't
deserve my help." Right?
Making empty claims is rather dubious.
Frankly, I am
already using components that I would never dream of describing as
"general" that already handle more possible (and actually likely)
permutations that your code would.
Even if you do have such components, they're useless to anyone but yourself,
since you refuse to share your work with the world. You just brag about it.
How nice of you.

I have a time machine, you know. I'm just not going to show it to you or
anyone else. Anyone smart enough to know how to handle a time machine should
be able to build one on their own.
Which is true. The question is what perverse use of English allows the
use of the label "general" with an algorithm that is not exhaustive.
This is more of your "partial solution" nonsense.
I'm just going to ignore your semantics arguments from now on. You often
prefer them to arguments about real concepts. One might take you for quite a
linguist, given how often you choose to argue about semantics, and how many
extra unnecessary words you choose to use in your posts to this group.
I know plenty of 'real' web sites that change their design
regularly,

You do appear to associate with some staggeringly inept web
developers.


I prefer to think that you associate with some staggeringly atypical web
sites and developers, probably at a size and cost that most people won't
ever touch. You do appear quite naive of the situations that many developers
find themselves in, and you seem to lack the ability to see the world
through anyone's eyes but your own.
Thinking here seems to be that re-designing a web site is
so expensive and time consuming that doing so at intervals of less
than six months would be pouring money down the drain.
I re-designed a site the other day and it took about 2 hours. Since it was
all PHP with templates, headers, footers, etc, the site had a whole
different look and feel in a short amount of time. Amazing, isn't it?
You edited out (again without marking the edit) my second, and more
important question, which was

<snip>

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 1 '05 #108

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
I unequivocally assert that a general algorithm must consider
every possible permutation, or is it not a general algorithm.
Semantic games bore me. Stop playing them.


You certainly don't seem to like being asked to pin down the precise
meaning of the statements you make.
To me, you are describing an "exhaustive solution".
I would not use the word 'solution' here at all, because in the context
of problem solving I regard a solution as an absolute, and so not
requiring qualification. But we seem to agree that an algorithm that
exhaustively covers every possible permutation is a general algorithm.
To me, a "general solution" is one which is written so as
to not be specific to a single situation, but can be applied
to a number of different situations (but not necessarily all).
And yesterday you were saying :-

| In fact, a "general" solution need only be tested in the
| situations that it claims to cover ...

- suggesting that the characteristic that made an algorithm 'general'
were the qualifications that accompanied it. An assertion that became
self-evidently ludicrous when demonstrated to be applicable to a totally
specific function.

Today you assert that the algorithm becomes 'general' when it applies to
more than one situation. This is a similarly hopeless criteria for
labelling an algorithm general as:-

function getYPosition(elRef){
return elRef.offsetTop;
}

- applies to more than one situation, but is a long way from deserving
the label 'general'.
You understand what I mean.
I understand a meaning of the sequences of words that you are using.
What I am not seeing is how they can be usefully applied to the practice
of writing computer software. Mostly because the terms that could be
precise are constantly undermined with questionable qualifications.
If you would like to use different words to describe
what you know I am talking about, let me know what your
preferred words are.
I am a linguistic nominalist so I don't really care about the terms
used. You can make-up and use entirely new terms for all I care, the
only impotent consideration is the we both understand how the terms used
relate to the other terms in statements that employ them. If we cannot
share an understanding of how a term is being used we cannot communicate
and use that term at the same time.

Your use of 'solution' is a good example. I may not approve of your
definition but I can understand it, and so I can understand the
statements that you make that employ it. Because you understand that
when I use the term 'solution' I am referring to 'that which negates the
problem as analysed' you can understand my use of the term 'solution'.
And because I understand that when you use the term 'solution' you mean:
'that which may or may not negate the problem as analysed, but sounds
positive regardless', I can understand your sue of 'solution'. So, for
example, when you write "partial solution" I know hat you mean the
category of solutions that do not negate the problem as analysed but
still sound positive.

Those mutual understandings facilitate communication.

What I am asking for here is that you explain what it is that you mean
when you use the term 'general' (which seems quite significant when you
assert that you are seeking general solutions/algorithms).

But lets not get hung up on the term 'general' as such. Instead lets
ditch the loaded term and substitute the arbitrary term 'x', and analyse
the relationship between x and algorithms more abstractly:-

The a-priory assumption is: -

1. x is a quality that an algorithm may or may not have.

And the axiomatic 'truths' are:-

1. An algorithm that is totally specific to a single context
and task does not exhaustively cover all possible
permutations (and the inverse).

2. An algorithm that exhaustively covers all possible
permutations has the quality x.

3. An algorithm that is totally specific to a single context
and task does not have the quality x.

Unfortunately the statements are not enough to deduce a definition of x.
To that end another statement needs to be added, and given that x
appears to relate to specificity-exhaustiveness we can expect this
statement to be couched in those terms.

One obvious candidate is that; 'An algorithm has the quality x if it is
not totally specific to a single context and task'. The second and third
statements above can be deduced from this assumption and the remaining
one and so they can then be removed. And the new assumption becomes the
definition of x.

The other obvious candidate is that; 'An algorithm does not have the
quaintly x if it does not exhaustively cover all possible permutations'.
Again the second and third statements can be deduced from this
assumption and the remaining one. And this assumption becomes the
definition of x.

The remaining, and unavoidable, possibility is that an algorithm's
possession of the quality x relates to something other. That a fourth
statement needs to be added defining a relationship between
specificity-exhaustiveness and x, or fourth and fifth statements, one
relating x to something else and the other relating that something else
back to specificity-exhaustiveness. This (these) addition(s) (if
satisfactory) should again allow statements 2 and 3 to be deduced.
Possibly, but not necessarily, when combined with the first.

So, any statement (or consistent sequence of statements) that,
independently of, or when combined with, the first statement made above,
allows the second and third statements above to be deduced is a
satisfactory definition of x.

Relating this back to the applicability of the term 'general'. Today you
have gone for; "To me, a "general solution" is one which is written so
as to not be specific to a single situation, but can be applied to a
number of different situations (but not necessarily all)". Thus 'all
algorithms are general if they are not totally specific to a single
context/task'. I don't like that definition because it is the most
inclusive definition possible, and leaves the term 'general' meaning
very little. But if that is the meaning you would like attached when you
use the term 'general' then that is fine. Say so and we can have an end
of it. Though don't be too surprised if you are taken at your word.

As I have said, I prefer the most exclusive definition; 'all algorithms
are not general if they do not exhaustively cover all possible
permutations'.

On the other hand I am happy to entertain any other definitions of
'general' that prescribes a cut-off somewhere in the spectrum between
the totally specific and the exhaustive. The important thing is to be
able to look at any algorithm and ask 'does this algorithm qualify for
the label "general" by the definition of general being used?' with the
expectation of being able to answer 'yes' or 'no'.
Then maybe you can stop arguing about words and
start discuss the concepts behind them.
Put the concept behind being 'general' into words that say something
about the subjects to which you want to apply the label and maybe the
concept can be discussed.
When the browser lays out the page, it calculates the
offsets for the element, given its position and display
type.

And when a browser calculates an offset where is it an
offset from?


Depends on the browser, of course. And the page contents.


And the CSS suggestions applying to the elements and their ancestors (as
defaulted or assigned).
See my test page at:
http://www.mattkruse.com/javascript/...sitionTest.php
It covers some of your conditions,

My conditions?


Yes, the long list of things that you said could be applied
to a given page to make a general position-finding function
impossible.


If you go back and read what I actually said you will find that I was
listing some of the factors that have to be taken into account in order
to make the general (by my preferred definition of the term) position
finding algorithm possible.
Things like adding borders, margins, etc. My example page
has test cases for some of those things, and no extra
consideration was needed to handle them correctly.
That is right, keep looking at test cases where the code works and
patting yourself on the back for their success. After all, you had your
general (by your apparently preferred definition) position finding
algorithm even before you realised a need to take scrollable elements
into account.
I saved your HTML locally, added one style attribute,
setting one CSS property, to one element on the page
and suddenly your little marker is half a page away
from where it was supposed to be.


What exactly was it that you changed?


I changed the value of one applicable CSS property on one element. You
will only find out where your code breaks by trying to break it.
Oh, wait, let me guess... "I'm not going to tell you,
because you don't deserve my help." Right?
Why do you act offended when I won't help you? All else being equal, am
I likely to go out of my way to help someone who insults me?
Making empty claims is rather dubious.
And disregarding warnings without testing is rather dangerous.
Frankly, I am already using components that I would never
dream of describing as "general" that already handle more
possible (and actually likely) permutations that your code
would.


Even if you do have such components, they're useless to anyone
but yourself,


And my employers.
since you refuse to share your work with the world.
You are not the world.
You just brag about it. How nice of you.
You won't goad me into sharing anything with you but the warnings I have
already given you. You don't seem to appreciate it but the reason that
you are interested in knowing the algorithms that I use for this task is
that I have already trodden the path that your have barley started
along.

You think my code might help you along that path, it won't. I came to
the point of being able to see that the path was a dead end, turned back
and took an alternative route. The code I use now deliberately
side-steps the issues inherent in the general position/dimension finding
problem, and in doing so it delivers results. But those issues cannot be
side-stepped on the rout you have chosen.

I have a time machine, you know.

<snip>

Excellent, problem solved then. All you have to do is go forward in time
to just after you publish the totally exhaustive general
position/dimension finding code, make a note of it, return home and
publish it. Then the only remaining question is whether I was right and
the result is too big and slow to be viable in any but the least
demanding circumstances.

Richard.

Nov 1 '05 #109

P: n/a
In article <dk*******@drn.newsguy.com>, Lee <RE**************@cox.net>
writes
John G Harris said:

In article <vq**************@merlyn.demon.co.uk>, Dr John Stockton
<jr*@merlyn.demon.co.uk> writes
<snip>
Agreed. The solution is to recast the sentence so that parseInt does
not come first. Putting "Function " before it is generally
satisfactory.
What a very silly thing to say.


It seems very reasonable to those of us who care about readability.


Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.

<snip>However, readability is much more important in the context of
documentation than in a dialog like that example.

I would have said:

The parseInt() or parseFloat() function should be used instead.
(except of course, that it should not).


But this makes you vulnerable to charges of being a pedantic twit, the
kind who gives bad advice, the kind of bad advice that leads to
unreadable documentation.

(We'll excuse the 'e' of "except" as a typing error).

John
--
John Harris
Nov 1 '05 #110

P: n/a
On Tue, 1 Nov 2005 19:17:42 -0000, in comp.lang.javascript , "Richard
Cornford" <Ri*****@litotes.demon.co.uk> in
<dk*******************@news.demon.co.uk> wrote:
Matt Kruse wrote:
Richard Cornford wrote:
I unequivocally assert that a general algorithm must consider
every possible permutation, or is it not a general algorithm.
Semantic games bore me. Stop playing them.


You certainly don't seem to like being asked to pin down the precise
meaning of the statements you make.
To me, you are describing an "exhaustive solution".


I would not use the word 'solution' here at all, because in the context
of problem solving I regard a solution as an absolute, and so not
requiring qualification. But we seem to agree that an algorithm that
exhaustively covers every possible permutation is a general algorithm.


There is no such thing as an (existent) absolute (and, yes, I will
gladly get into an involved ontological discussion and will bring up
Augustine at the drop of a hat) nor are there meaningful solutions
that deal with "every possible" permutation for significant problems.
The perfect is the enemy of the good. Engineering, and programming is
a branch of engineering not of math, deals with making good enough
cost effective solutions for the actual problem someone has. We try to
generalize solutions, but that requires knowing the appropriate
generalization. Having a function ReturnFour when you need to add 2
and 2 is nonsense. But so is something that can do complex arithmetic
and add vectors and matrixes and such when all you need is normal
arithmetic. Sometimes it is better to significantly restrict the
domain, this allows better performance and more appropriate routines.

[snip]
Relating this back to the applicability of the term 'general'. Today you
have gone for; "To me, a "general solution" is one which is written so
as to not be specific to a single situation, but can be applied to a
number of different situations (but not necessarily all)". Thus 'all
algorithms are general if they are not totally specific to a single
context/task'. I don't like that definition because it is the most
inclusive definition possible, and leaves the term 'general' meaning
very little. But if that is the meaning you would like attached when you
use the term 'general' then that is fine. Say so and we can have an end
of it. Though don't be too surprised if you are taken at your word.


General and specific are not absolute notions but, rather, relative
concepts. A routine can be more general than another and more specific
than yet another. (This is not commutative since we can measure on
multiple dimensions.)

[snip]
--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"
Nov 1 '05 #111

P: n/a
Thomas 'PointedEars' Lahn said the following on 10/31/2005 11:45 AM:
VK wrote:

I was following this discussion and wondering: what in the name these
fisherman's talks have to do with the announced topic?

Don't even try to bother to understand it. Most certainly it will go over
your head.

My wild guess would be [...]

Of course, this is the only level of thinking you appear to be capable of.


It is ad hominem moments like this that make people wonder about you
Thomas. Skip them and everyone will benefit.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices -
http://www.mattkruse.com/javascript/bestpractices/
Nov 1 '05 #112

P: n/a
Richard Cornford wrote:
What exactly was it that you changed? I changed the value of one applicable CSS property on one element. You
will only find out where your code breaks by trying to break it.


You're so predictable.

You claim that you break someone's code, but refuse to tell them how or
where. So no one knows if you really found a problem or if you're just
blowing smoke. Which is how you like it, because to you it's all about
bragging and telling others how stupid they are. Good for you!
You think my code might help you along that path, it won't.


I think you _might_ have some solutions which _might_ me resolve quirks in
browsers, etc.
Or maybe not. I've looked into your code and found problems with some of it
before, so I'm not confident that looking closely at your methods would even
provide me with something valuable.

I'm more interested in discussing the issues and challenges involved with a
group of developers. On this topic and others. I'm actually not all that
interested in your specific solutions, because although you might be
technically skilled, you're just not that pleasant of a person.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 1 '05 #113

P: n/a
Matt Kruse said the following on 11/1/2005 3:53 PM:

<snip>
I'm more interested in discussing the issues and challenges involved with a
group of developers. On this topic and others. I'm actually not all that
interested in your specific solutions, because although you might be
technically skilled, you're just not that pleasant of a person.


Any chance of a shorter URL to
http://www.mattkruse.com/javascript/bestpractices/
?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices -
http://www.mattkruse.com/javascript/bestpractices/
Nov 1 '05 #114

P: n/a
Randy Webb wrote:
Any chance of a shorter URL to
http://www.mattkruse.com/javascript/bestpractices/
?


Yup,
http://www.JavascriptToolbox.com/bestpractices/

I'm (very slowly) designing the new site and updating my code and examples
along with it. For now, it redirects to my personal site, but I prefer to
use the new url because that's where things will stay permanently.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 1 '05 #115

P: n/a
Matt Silberstein wrote:
Richard Cornford wrote:
Matt Kruse wrote:
To me, you are describing an "exhaustive solution".
I would not use the word 'solution' here at all, because
in the context of problem solving I regard a solution as
an absolute, and so not requiring qualification. But we
seem to agree that an algorithm that exhaustively covers
every possible permutation is a general algorithm.


There is no such thing as an (existent) absolute


Absolutely none? ;)
(and, yes,
I will gladly get into an involved ontological discussion
and will bring up Augustine at the drop of a hat) nor are
there meaningful solutions that deal with "every possible"
permutation for significant problems.
You have just introduced a category of problems that you have classed
'significant'. If you now define a 'significant' problem as one for
which it is not possible to deal with every possible permutation in a
meaningful solution you will have made a statement that is automatically
true, but not really worth much.

I suppose that in the context of the discussion to date the question
would be whether creating a general position/dimension reporting
algorithm is a 'significant' problem, and/or whether that algorithm
could take into account all of the possible permutations. I am fairly
sure that the variables, and the values of those variables, that
influence the position/dimensions of an element in a browser's DOM are
finite and knowable. It remains unclear whether a script executing in a
browser can identify, deduce and/or distinguish those variables/values.
I used to think that distinguishing some of the influencing variables
from each other was impossible. I have since noticed that there is a
possible way into that problem, and so that it could be possible to take
all of the possible permutations for that algorithm into account. But I
have never actually tried because the way in that I noticed is so
processing intensive that I doubt that the outcome would be worthwhile.
The perfect is the enemy of the good.
I like to think of the concept of perfect providing direction for the
better.
Engineering, and programming is a branch of engineering
That is disputed, there are plenty of experienced programmers who see it
as closer to an art.
not of math, deals with making good enough
cost effective solutions for the actual problem someone has.
Absolutely. But a solution that is 'good enough' is a solution to the
problem. It may not be the only solution to the problem, the best
solution to the problem, or an ideal solution to the problem, but being
good enough makes it a solution to the problem. And if a solution is
acceptable ('good enough') and is being described as a 'partial
solution' to some stated problem then the problem has been incorrectly
identified, and it is the problem for which the solution is acceptable
that was really the problem.

It seems to me that if programming is to be an engineering discipline
then accurately analysing the problems to be solved is a pre-requisite,
And precisely and unambiguously stating that problem should be a
considerable contribution to identifying a solution.
We try to generalize solutions, but that requires knowing
the appropriate generalization. Having a function ReturnFour
when you need to add 2 and 2 is nonsense. But so is something
that can do complex arithmetic and add vectors and matrixes
and such when all you need is normal arithmetic.
So there is a worthlessly trivial extreme and a pointlessly over the top
extreme. They don't exclude the possibility of covering all of the
factors pertinent to the problem.
Sometimes it is better to significantly restrict the
domain, this allows better performance and more
appropriate routines.
Which is one of the advantages of the strategy that I have been
proposing. You observe that any real context does not include all of the
factors that may apply in the general context, and only code for the
factors that do apply in the specific context. But do that in a way that
allows the context specific code to be swapped for more appropriate code
if and when the context is changed.
[snip]
Relating this back to the applicability of the term 'general'. ...
<snip> General and specific are not absolute notions but, rather,
relative concepts. A routine can be more general than another
and more specific than yet another. (This is not commutative
since we can measure on multiple dimensions.)


The ability to be more (or less) general, and more (or less) specific
does not preclude the possibility that general and specific are both
absolute. And neither does the fact that both may be applied to the same
subject when describing different aspects of that subject.

Richard.
Nov 2 '05 #116

P: n/a
Lee
John G Harris said:
Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.
You're not in a majority, you know. What seems like utter
nonsense to you is a well established standard.

<snip>
However, readability is much more important in the context of
documentation than in a dialog like that example.

I would have said:

The parseInt() or parseFloat() function should be used instead.
(except of course, that it should not).


But this makes you vulnerable to charges of being a pedantic twit, the
kind who gives bad advice, the kind of bad advice that leads to
unreadable documentation.

(We'll excuse the 'e' of "except" as a typing error).


The typing error was actually the period after "instead".
The parenthetical remark is a continuation of the sentence.

Nov 2 '05 #117

P: n/a
On Wed, 2 Nov 2005 00:53:56 -0000, in comp.lang.javascript , "Richard
Cornford" <Ri*****@litotes.demon.co.uk> in
<dk*******************@news.demon.co.uk> wrote:
Matt Silberstein wrote:
Richard Cornford wrote:
Matt Kruse wrote:
To me, you are describing an "exhaustive solution".

I would not use the word 'solution' here at all, because
in the context of problem solving I regard a solution as
an absolute, and so not requiring qualification. But we
seem to agree that an algorithm that exhaustively covers
every possible permutation is a general algorithm.
There is no such thing as an (existent) absolute


Absolutely none? ;)
(and, yes,
I will gladly get into an involved ontological discussion
and will bring up Augustine at the drop of a hat) nor are
there meaningful solutions that deal with "every possible"
permutation for significant problems.


You have just introduced a category of problems that you have classed
'significant'.


I am not interested in perfect solutions to trivial problems.
If you now define a 'significant' problem as one for
which it is not possible to deal with every possible permutation in a
meaningful solution you will have made a statement that is automatically
true, but not really worth much.
Significant problems are one where you have to think about and the
results matter. It is a term of art, this is not a philosophy
discussion.
I suppose that in the context of the discussion to date the question
would be whether creating a general position/dimension reporting
algorithm is a 'significant' problem, and/or whether that algorithm
could take into account all of the possible permutations. I am fairly
sure that the variables, and the values of those variables, that
influence the position/dimensions of an element in a browser's DOM are
finite and knowable. It remains unclear whether a script executing in a
browser can identify, deduce and/or distinguish those variables/values.
I used to think that distinguishing some of the influencing variables
from each other was impossible. I have since noticed that there is a
possible way into that problem, and so that it could be possible to take
all of the possible permutations for that algorithm into account. But I
have never actually tried because the way in that I noticed is so
processing intensive that I doubt that the outcome would be worthwhile.
The perfect is the enemy of the good.
I like to think of the concept of perfect providing direction for the
better.


Concept of? Perhaps. But it is not an valuable goal.
Engineering, and programming is a branch of engineering


That is disputed, there are plenty of experienced programmers who see it
as closer to an art.


Not a contradiction. Engineering has lots of art involved. Even "real"
engineers, structural and all that, still has art involved.
not of math, deals with making good enough
cost effective solutions for the actual problem someone has.


Absolutely. But a solution that is 'good enough' is a solution to the
problem. It may not be the only solution to the problem, the best
solution to the problem, or an ideal solution to the problem, but being
good enough makes it a solution to the problem. And if a solution is
acceptable ('good enough') and is being described as a 'partial
solution' to some stated problem then the problem has been incorrectly
identified, and it is the problem for which the solution is acceptable
that was really the problem.


A good enough solution has to deal with enough of the cases that will
occur, not everything that ever might happen. I can make a totally
secure computer. Just remove the network cable. Remove USB ports.
Remove serial and parallel ports. Remove the modem. Remove the
keyboard and mouse and display. And take a way the power cord and
smash the hard drive. Ok, so maybe that is not applicable, I just like
to write it.
It seems to me that if programming is to be an engineering discipline
then accurately analysing the problems to be solved is a pre-requisite,
And precisely and unambiguously stating that problem should be a
considerable contribution to identifying a solution.


Which does not mean dealing with everything and anything that could
happen.
We try to generalize solutions, but that requires knowing
the appropriate generalization. Having a function ReturnFour
when you need to add 2 and 2 is nonsense. But so is something
that can do complex arithmetic and add vectors and matrixes
and such when all you need is normal arithmetic.


So there is a worthlessly trivial extreme and a pointlessly over the top
extreme. They don't exclude the possibility of covering all of the
factors pertinent to the problem.


And "pertinent" is the question that matters. I saw you writing about
absolutes and all factors, not all pertinent or figuring the
appropriate general case.
Sometimes it is better to significantly restrict the
domain, this allows better performance and more
appropriate routines.


Which is one of the advantages of the strategy that I have been
proposing. You observe that any real context does not include all of the
factors that may apply in the general context, and only code for the
factors that do apply in the specific context. But do that in a way that
allows the context specific code to be swapped for more appropriate code
if and when the context is changed.
[snip]
Relating this back to the applicability of the term 'general'. ...

<snip>
General and specific are not absolute notions but, rather,
relative concepts. A routine can be more general than another
and more specific than yet another. (This is not commutative
since we can measure on multiple dimensions.)


The ability to be more (or less) general, and more (or less) specific
does not preclude the possibility that general and specific are both
absolute. And neither does the fact that both may be applied to the same
subject when describing different aspects of that subject.


--
Matt Silberstein

Do something today about the Darfur Genocide

http://www.beawitness.org
http://www.darfurgenocide.org
http://www.savedarfur.org

"Darfur: A Genocide We can Stop"
Nov 2 '05 #118

P: n/a
Matt Silberstein wrote:
Richard Cornford wrote: <snip>
There is no such thing as an (existent) absolute


Absolutely none? ;)
(and, yes,
I will gladly get into an involved ontological discussion
and will bring up Augustine at the drop of a hat) nor are
there meaningful solutions that deal with "every possible"
permutation for significant problems.


You have just introduced a category of problems that you have
classed 'significant'.


I am not interested in perfect solutions to trivial problems.


Another class of problem labelled 'trivial'? I assume these two classes
would be exclusive but not exhaustive.
If you now define a 'significant' problem as one for
which it is not possible to deal with every possible
permutation in a meaningful solution you will have made
a statement that is automatically true, but not really
worth much.


Significant problems are one where you have to think about
and the results matter.


As reasonable a definition as most others. So something like doing basic
arithmetic accurately, which might seem trivial, becomes significant if
you are doing it in the context of a banking or and aeroplane
fly-by-wire system, because the results will matter.
It is a term of art, this is not a philosophy
discussion.
So Augustine is no longer weighting in the wings then? ;)

<snip>
The perfect is the enemy of the good.


I like to think of the concept of perfect providing
direction for the better.


Concept of? Perhaps. But it is not an valuable goal.


Surly that depends on how easy it is to achieve. There is no problem in
accepting that perfection is impractical and/or unachievable in many
cases, but sometimes (if possibly rarely) the objectively prefect may be
trivially achieved. In which case why not?

<snip>
... , deals with making good enough cost effective
solutions for the actual problem someone has.


Absolutely. But a solution that is 'good enough' is a solution to the
problem. It may not be the only solution to the problem, the best
solution to the problem, or an ideal solution to the problem, but
being good enough makes it a solution to the problem. And if a
solution is acceptable ('good enough') and is being described as a
'partial solution' to some stated problem then the problem has been
incorrectly identified, and it is the problem for which the solution
is acceptable that was really the problem.


A good enough solution has to deal with enough of the cases
that will occur,


Where 'enough' is determined by the actual problem.
not everything that ever might happen. I can make a totally
secure computer. ...


You could, but given that your totally secure computer is a pretty
useless object, was creating a 'totally secure computer' really the
outcome of the problem analysis or just a vague first attempt by someone
at stating the problem domain?

<snip>
It seems to me that if programming is to be an engineering
discipline then accurately analysing the problems to be
solved is a pre-requisite, And precisely and unambiguously
stating that problem should be a considerable contribution
to identifying a solution.


Which does not mean dealing with everything and anything that
could happen.


No, but it does mean at least having a go at identifying everything that
is relevant to the real problem (and those things that may appear
relevant but are not).

<snip>
So there is a worthlessly trivial extreme and a pointlessly
over the top extreme. They don't exclude the possibility of
covering all of the factors pertinent to the problem.


And "pertinent" is the question that matters. I saw you
writing about absolutes and all factors, not all pertinent
or figuring the appropriate general case.

<snip>

And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can be
drooped unaltered into any web page context at all and will then
successfully function as expected. And his expectation is that the
person doing the dropping will not have any technical understanding of
what they are doing and so will be incapable of doing anything about it
when his products do not work as expected.

That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot be
dropped into any web page context. With the latter case suggesting that
Matt should state the restricted contexts in which the code can be
successfully used, and that the individual employing the code should be
able to recognise whether those restrictions are satisfied in their
particular situation (problematic given the pre-supposition that this
individual has no understanding of the technologies they are using).

Of course that is just the logic of what Matt purports to be doing. When
'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks like a
marketing exercise rather than the altruistic contribution to the
betterment of the web development world he sometimes makes it out to be.

Which significantly alters the problem analysis, as then it is only
necessary to produce code that gives the impression of being general to
a sufficiently large number of individuals (who will never (mostly could
never) try to test that claim) to produce a revenue stream sufficient to
fund the exercise. Unfortunately that revenue stream comes form
voluntary donations and google adds. The latter requiring him to
constantly direct people to the pages on which those adds appear and the
former necessitating the maintenance of the pretence that the whole
exercise is altruistic. Hence; his desire to paint himself as the
champion of the common web developer, man of the people and victim of an
oppressive elite. His dislike of having the meaning of his statements
questions, his unwillingness to elaborate upon them and his reluctance
to say whether the clients of a professional should have a reasonable
expectation that that professional understands what they are doing. Of
course all of these things must also be denied in order to maintain the
pretence, but that's just marketing.

Richard.
Nov 2 '05 #119

P: n/a
In article <dk********@drn.newsguy.com>, Lee <RE**************@cox.net>
writes
John G Harris said:
Adding redundant words will sometimes improve readability, but adding
them simply to avoid starting a sentence with a trademark such as "eBay"
is utter nonsense.


You're not in a majority, you know. What seems like utter
nonsense to you is a well established standard.

<snip>

Are you sure your majority insist that a rule making paragraphs easier
to read justifies destroying the meaning in some infrequent cases?

Incidentally, there's a rule that proper nouns have a leading capital,
words like Lee, London, eBay, and parseInt.

John
--
John Harris
Nov 2 '05 #120

P: n/a
Let's clear things up...

Richard Cornford wrote:
And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can
be drooped unaltered into any web page context at all and will then
successfully function as expected.
'Ideally', yes, that would be nice. Realistically, no. That's not the goal.
The goal would be able to have code which works when dropped into the
majority of typical situations.
And his expectation is that the
person doing the dropping will not have any technical understanding of
what they are doing and so will be incapable of doing anything about
it when his products do not work as expected.
If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the code. If
it is likely that the condition is common to more than just a single
situation, then it could be considered for addition.
That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot
be dropped into any web page context.
Perhaps you used wrong words, but that is not true at all.
Even if all factors are not considered, it might work correctly in the
majority of contexts.
Your point, I assume, is that unless all contexts are considered, then it
could not be dropped into ALL web page contexts. Which is, of course, true.
But since that is never my goal, I have no problem with that.
With the latter case suggesting
that Matt should state the restricted contexts in which the code can
be successfully used, and that the individual employing the code
should be able to recognise whether those restrictions are satisfied
in their particular situation
It's impossible to list every context where such a generalized solution will
work. It might be possible to list all the conditions that are considered in
the code, although I don't think most people would find value in that.
Instead, it would be best to list the contexts where the code does _not_
work, so a user can identify if such a context exists in their case.
When 'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks
like a marketing exercise rather than the altruistic contribution to
the betterment of the web development world he sometimes makes it out
to be.
I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case. For example, if you
have an IE-only app and you want to get the color applied to an object, you
could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}

This solution is not generalized at all. It returns the value of one
attribute, and only in some user agent(s).

The term 'general' is relative. A 'more general' solution would take into
account multiple user agents:

function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue('color');
}
return null;
}

A even more 'general' solution would consider the case of a null object,
etc, but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an argument, so
the method could be reused for obtaining any style attribute:

function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue(property);
}
return null;
}

An EVEN MORE 'general' solution might take into consideration some specific
browser quirks, or NN4, etc.

I would consider the improved 'getObjectColor' function to be a general
method of obtaining the color of an object. But the 'getObjectStyleValue'
method is even better, since it's a general method to obtain any style
value.

None of these are 'exhaustive' solutions, however. There are certainly cases
and browser quirks which are not considered. However, these functions in
their finished form would surely provide the desired functionality for most
people in most contexts, so they could be presented as a 'general' solution.

The goal of building 'general' solutions is to provide functionality that
works in the majority of contexts that arise in typical development. The
goal is never to build an exhaustive solution which covers all possible
situations. That's not possible in most cases. (In cases where it is
possible, it is certainly a good goal!)

Your insistance that a 'general' solution must be 'exhaustive' is incorrect
(or at least, not the typical opinion). I've checked with a number of other
developers in a forum I participate in, and they all agreed that they do not
necessarily consider a 'general' solution to address every possible need
which might arise.

So, when I attempt to build a 'general' solution for finding the position of
an object, for example, I'm attempting to address the majority of typical
contexts in which it would be used. So most people, under most conditions,
_could_ in fact drop the library into their code and have it work correctly.
In other libraries, I have built in functionality which will be used by some
people but not others, because I thought that the need for the functionality
was typical enough to warrant inclusion. In other cases, people have made
specific requests that I did not include because I didn't think most people
would ever have the need for the feature.

If exceptions happen (and they will) then I would hope that the person
finding it would tell me details and provide a test case so I could
determine if the need is typical enough (in my own opinion) to be included
in the general library and should be fixed, or if their context is so
specific to their situation that they would need to write specific code for
their case. Of course, when people such as yourself claim to find an
exception and refuse to provide details or a test case, that doesn't help to
make the general routine more solid. In fact, since you refuse to provide
any evidence, I'm not sure I even believe you. It's easy to make empty
claims. *shrug*

A 'partial solution' is valuable because it solves a specific case and can
be used in a more general solution. For example, the code using currentStyle
to find the style applied to an object is a 'partial solution' because it
does solve the problem for a subset of all cases. Combined with other
'partial solutions' they form a more general solution which is more
valuable.

A 'partial solution' can also be a library in itself. For example, finding
the position of an object. By itself, it provides no functionality to the
user. It must be used with other code to achieve some bigger goal. But it
can be used as a black box to solve the problem of finding the position of
an object, so the coder doesn't need to go into detail programming that
portion of the bigger picture.
<snip about my 'advertising' and supposed real motivations>


Nothing will change your opinion of my efforts, Richard, so what I write
won't even matter.

But, the truth is that when I direct people to my stuff, it's always because
it _specifically_ addresses their needs, and I think they will benefit from
it. I don't advertise. If you have specific code which solves their specific
problem, you may post it. If I have already written a solution which solves
their problem, I may direct them to it.

I happen to offset the cost and development time with donations and google
ads, although I certainly do not 'come out ahead' in the game. If I were
trying to make a profit, I would be charging for my work rather than giving
it away with almost no useage restrictions. My goal is to provide solutions
which help average web developers perform complex tasks which they may not
be able to do themselves. I get personal satisfaction knowing that I've
helped thousands of people solve their problems when people like you would
have told them that they didn't even deserve to be helped. If I'm ever seen
as 'promoting' my stuff, it's because I want people to be made aware of
packaged solutions which can solve their problem, rather than being faced
with people telling them how stupid they are, or resorting to finding
terrible code at some copy-n-paste javascript site.

If you don't believe me, that's fine. I don't care.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 2 '05 #121

P: n/a
Richard, perhaps you missed this followup...

You had asked for me to be clearer about what I meant by 'general' and
'exhaustive' and 'partial solution'.
I was curious if you had a response after I made things clearer?

Matt
Matt Kruse wrote:
Let's clear things up...

Richard Cornford wrote:
And I was writing about Matt's specific problem. In theory he has the
problem of the general. Ideally he wants to create something that can
be drooped unaltered into any web page context at all and will then
successfully function as expected.


'Ideally', yes, that would be nice. Realistically, no. That's not the
goal. The goal would be able to have code which works when dropped
into the majority of typical situations.
And his expectation is that the
person doing the dropping will not have any technical understanding
of what they are doing and so will be incapable of doing anything
about it when his products do not work as expected.


If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the
code. If it is likely that the condition is common to more than just
a single situation, then it could be considered for addition.
That means either Matt's code takes into account all the factors
pertinent to its being dropped into any web page context or it cannot
be dropped into any web page context.


Perhaps you used wrong words, but that is not true at all.
Even if all factors are not considered, it might work correctly in the
majority of contexts.
Your point, I assume, is that unless all contexts are considered,
then it could not be dropped into ALL web page contexts. Which is, of
course, true. But since that is never my goal, I have no problem with
that.
With the latter case suggesting
that Matt should state the restricted contexts in which the code can
be successfully used, and that the individual employing the code
should be able to recognise whether those restrictions are satisfied
in their particular situation


It's impossible to list every context where such a generalized
solution will work. It might be possible to list all the conditions
that are considered in the code, although I don't think most people
would find value in that. Instead, it would be best to list the
contexts where the code does _not_ work, so a user can identify if
such a context exists in their case.
When 'providing general solutions' uses general to mean no more than
non-specific and solutions may be 'partial' the whole thing looks
like a marketing exercise rather than the altruistic contribution to
the betterment of the web development world he sometimes makes it out
to be.


I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case. For example, if
you have an IE-only app and you want to get the color applied to an
object, you could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}

This solution is not generalized at all. It returns the value of one
attribute, and only in some user agent(s).

The term 'general' is relative. A 'more general' solution would take
into account multiple user agents:

function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue('color');
}
return null;
}

A even more 'general' solution would consider the case of a null
object, etc, but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an
argument, so the method could be reused for obtaining any style
attribute:
function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue(property);
}
return null;
}

An EVEN MORE 'general' solution might take into consideration some
specific browser quirks, or NN4, etc.

I would consider the improved 'getObjectColor' function to be a
general method of obtaining the color of an object. But the
'getObjectStyleValue' method is even better, since it's a general
method to obtain any style value.

None of these are 'exhaustive' solutions, however. There are
certainly cases and browser quirks which are not considered. However,
these functions in their finished form would surely provide the
desired functionality for most people in most contexts, so they could
be presented as a 'general' solution.
The goal of building 'general' solutions is to provide functionality
that works in the majority of contexts that arise in typical
development. The goal is never to build an exhaustive solution which
covers all possible situations. That's not possible in most cases.
(In cases where it is possible, it is certainly a good goal!)

Your insistance that a 'general' solution must be 'exhaustive' is
incorrect (or at least, not the typical opinion). I've checked with a
number of other developers in a forum I participate in, and they all
agreed that they do not necessarily consider a 'general' solution to
address every possible need which might arise.

So, when I attempt to build a 'general' solution for finding the
position of an object, for example, I'm attempting to address the
majority of typical contexts in which it would be used. So most
people, under most conditions, _could_ in fact drop the library into
their code and have it work correctly. In other libraries, I have
built in functionality which will be used by some people but not
others, because I thought that the need for the functionality was
typical enough to warrant inclusion. In other cases, people have made
specific requests that I did not include because I didn't think most
people would ever have the need for the feature.
If exceptions happen (and they will) then I would hope that the person
finding it would tell me details and provide a test case so I could
determine if the need is typical enough (in my own opinion) to be
included in the general library and should be fixed, or if their
context is so specific to their situation that they would need to
write specific code for their case. Of course, when people such as
yourself claim to find an exception and refuse to provide details or
a test case, that doesn't help to make the general routine more
solid. In fact, since you refuse to provide any evidence, I'm not
sure I even believe you. It's easy to make empty claims. *shrug*

A 'partial solution' is valuable because it solves a specific case
and can be used in a more general solution. For example, the code
using currentStyle to find the style applied to an object is a
'partial solution' because it does solve the problem for a subset of
all cases. Combined with other 'partial solutions' they form a more
general solution which is more valuable.

A 'partial solution' can also be a library in itself. For example,
finding the position of an object. By itself, it provides no
functionality to the user. It must be used with other code to achieve
some bigger goal. But it can be used as a black box to solve the
problem of finding the position of an object, so the coder doesn't
need to go into detail programming that portion of the bigger picture.
<snip about my 'advertising' and supposed real motivations>


Nothing will change your opinion of my efforts, Richard, so what I
write won't even matter.

But, the truth is that when I direct people to my stuff, it's always
because it _specifically_ addresses their needs, and I think they
will benefit from it. I don't advertise. If you have specific code
which solves their specific problem, you may post it. If I have
already written a solution which solves their problem, I may direct
them to it.
I happen to offset the cost and development time with donations and
google ads, although I certainly do not 'come out ahead' in the game.
If I were trying to make a profit, I would be charging for my work
rather than giving it away with almost no useage restrictions. My
goal is to provide solutions which help average web developers
perform complex tasks which they may not be able to do themselves. I
get personal satisfaction knowing that I've helped thousands of
people solve their problems when people like you would have told them
that they didn't even deserve to be helped. If I'm ever seen as
'promoting' my stuff, it's because I want people to be made aware of
packaged solutions which can solve their problem, rather than being
faced with people telling them how stupid they are, or resorting to
finding terrible code at some copy-n-paste javascript site.
If you don't believe me, that's fine. I don't care.


--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 5 '05 #122

P: n/a
Matt Kruse wrote:
Richard, perhaps you missed this followup...


Give me a chance, i have had a lot to do recently.

Richard.
Nov 7 '05 #123

P: n/a
Matt Kruse wrote:
Let's clear things up...

Richard Cornford wrote:
And I was writing about Matt's specific problem. In theory
he has the problem of the general. Ideally he wants to create
something that can be drooped unaltered into any web page
context at all and will then successfully function as expected.
'Ideally', yes, that would be nice. Realistically, no. That's not
the goal. The goal would be able to have code which works when
dropped into the majority of typical situations.


Then why do you talk about your code being general when you are only
asking it to be braod?
And his expectation is that the person doing the dropping will
not have any technical understanding of what they are doing
and so will be incapable of doing anything about it when his
products do not work as expected.


If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the
code.


If the person doing the dropping has no technical understanding of what
they are doing then they are unlikely to be able to create a test case,
and more likely to go off an look for alternative code that seems to
better suite their situation (although the 'low hanging fruit' attitude
among the authors of such code means that they are likely to be
unsuccessful).

<snip>
When 'providing general solutions' uses general to mean no
more than non-specific and solutions may be 'partial' the
whole thing looks like a marketing exercise rather than the
altruistic contribution to the betterment of the web development
world he sometimes makes it out to be.


I've thought about definitions a bit, and I offer this...

A specific solution is only useful in a single case.


Th concept of 'specific' might be the harder one to pin down. With this
definition it may become necessary to consider how singular a single
case is.
For example, if you have an IE-only app and you want to get
the color applied to an object, you could use:

function getObjectColor(obj) {
return obj.currentStyle.color;
}
The singleness in this case being a browser implementing a single
feature. While:-

function getObjectColor() {
return document.getElementById('anId').currentStyle.color ;
}

- applies to a single element on a browser implementing a single
feature, and so is more specific.
This solution is not generalized at all.
Because the first is less specific than the second it is also more
general.
It returns the value of one
attribute, and only in some user agent(s).
As opposed to the return value of one attribute on one element and only
on some user agents.
The term 'general' is relative.
You haven't precluded the possibility of 'general' being an absolute.
Being able to talk of 'more general', 'less general', 'more specific'
and 'less specific' certainly doesn't achieve that. Consider a row of 11
glasses; the first is left empty, the second has 10% or its volume
filled with water, the third 20%, the fourth 30%, and so on until the
last has 100% of its volume filled with water. It is possible to pick
any two glasses and say this one is 'more full' than that one, and that
one is 'more empty' that this one. But still only one glass _is_ empty,
and all the rest are _not_ empty, and one glass _is_ full and all the
rest are _not_ full.

It is a characteristic of the concepts of full and empty that you cannot
make a glass 'more full' than full and you cannot make a glass 'more
empty' than empty. (Granted someone might quibble that an empty glass
was full of air and insist that a glass in a vacuum was more empty, but
they would still have to accept that there is a point where that glass
could not be rendered more empty).
A 'more general' solution would take
into account multiple user agents:
Above you stated "if you have an IE-only app and you want to get the
color applied to an object", which states, if imprecisely, the problem.
This "'more general' solution" is not a more general solution to that
problem (the solution you had was as general a solution to that problem
as is needed). This is a possible solution for a more general problem.
This second problem may be expressed as:-

Retrieve the currently applicable (non-normalised) value of the CSS
'color' property as a string from any Element whenever that information
is available or a distinguishable alternative when it is not available.
function getObjectColor(obj) {
if (obj.currentStyle) {
return obj.currentStyle.color;
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue(
'color');
}
return null;
}
Disregarding the technical flaws (the use of obj.document instead of
obj.ownerDocument and the failure to verify that the computed style
object implements a - getPropertyValue - method) and the broken
presentation, that is very close to being a general solution to the
problem I stated above. The only environment permutations it does not
exploit are the possibility that where the - getPropertyValue - method
is not implemented on the computed style object the value may still be
available as the - color - property of that object or may be
reconstructed through the use of the - getPropertyCSSValue - and the -
CSSValue -interface (if available).

The sense in which this may be regarded as a more general solution is
that it is a solution to a more general problem, that happens to
encompass the originally stated problem. It can be applied to the
problem of retrieving the color of an element on IE, because IE (al
least IE 5+) is a browser where the information is available. It won't
do the job any better than the original (because it won't do anything
differently) and might be regarded as a worse solution because of the
need to download code that will never be executed in the context of the
IE only problem.
A even more 'general' solution would consider the case of
a null object, etc,
Again that is not a more general solution to the problem it is a
solution to a more general problem. Specifically, instead of stipulating
that the parameter should be an Element the problem now asserts that any
parameter must be handled (suggesting that some verification that the
parameter actually is an Element happen before passing it to the -
getComputedStyle - method), or that the parameter be and Element or null
(much easier to test).

Design wise I wouldn't bother. Better to have the code that calls this
function verify the parameter before the call as it is likely to still
have an interest in the Element-ness of the object when it gets the
return value.
but I will not list that here for the sake of brevity.

An EVEN MORE 'general' solution could take the property as an
argument, so the method could be reused for obtaining any style
attribute:
Or it is a solution to the more general problem:-

Retrieve the currently applicable (non-normalised) value an arbitrary
CSS property as a string from any Element whenever that information is a
vailable or a distinguishable alternative when it is not available.
function getObjectStyleValue(obj,property) {
if (obj.currentStyle) {
return obj.currentStyle[property];
}
else if (obj.document && obj.document.defaultView &&
obj.document.defaultView.getComputedStyle) {
return
obj.document.defaultView.getComputedStyle(obj,''). getPropertyValue(
property);
}
return null;
}
The nice thing about this more general problem is that once it has been
solved its solution also negates the problem of retrieving all specific
CSS property values. However, in the event that the problem in context
is the retrieval of the 'color' property the actual solution to that
problem is calling this function with 'color' as its parameter.

But what happens if this more general problem cannot be solved? Can the
function that only returns the CSS color property be regarded as a
'partial solution' to this more general problem. We know that it will
return a correct and useful value for a subset of possible parameters.
Would it become a 'partial solution' when that subset became the
majority of possible parameters?

Or if we use it in a context where the majority of CSS property
retrievals are for 'color' and so we mostly get the correct answer. Does
that make it a 'partial solution' to the more general problem?

And if we use it in a context where the only CSS property we are
interested in is 'color'? The results will be no worse than would be
expected from the solution to the more general problem. Does achieving
the same results in a restricted context make retrieving the color alone
a 'partial solution' to the problem of retrieving any arbitrary CSS
property's value?

I don't think that there is such a thing as a 'partial solution', just
poorly identified/defined problems. The solution to a more general
problem may be regarded as a more general solution because it will
negate a set of related but more specific problems, but the solution to
any subset of those more specific, related problems are never a less
general solution to the more general problem. They are a failure to
solve the more general problem (even when the more general problem
didn't actually need solving and the solutions to some of its more
specific related problems are enough to get the job done).
An EVEN MORE 'general' solution might take into consideration
some specific browser quirks, or NN4, etc.
(Netscape 4 is a browser quirk :)

Which is actually a 'better' solution to the problem of getting the
value whenever that information is available, as it recognises that
there are some other places where the information may be available.
I would consider the improved 'getObjectColor' function to be a
general method of obtaining the color of an object.
It is certainly close to being as general a method as any could be.
But the 'getObjectStyleValue' method is even better, since
it's a general method to obtain any style value.

None of these are 'exhaustive' solutions, however. There are
certainly cases and browser quirks which are not considered.
However, these functions in their finished form would surely
provide the desired functionality for most people in most
contexts, so they could be presented as a 'general' solution.
The ability to present anything as a general solution is not in doubt.
How justified that assertion would be is a different matter. Given how
wrong the output of that function will be in some contexts it does not
seem reasonable to consider it general just because it will behave as
expected in most contexts.
The goal of building 'general' solutions is to provide
functionality that works in the majority of contexts that
arise in typical development.
No, that is the goal of providing functionality that will work in the
majority of contexts that typically arise in development.
The goal is never to build an exhaustive solution
which covers all possible situations.
Never? Why not? If it is trivial to produce exhaustive code then that
satisfies a requirement to provide code that works in the majority of
contexts that typically arise.
That's not possible in most cases. (In cases where it is
possible, it is certainly a good goal!)
Precisely. But these confusions and contradictions on your part appear
to stem form applying woolly thinking to the task of identifying the
problem that is to be solved.
Your insistance that a 'general' solution must be 'exhaustive'
is incorrect (or at least, not the typical opinion).
Typical of who exactly?
I've checked with a number of other developers in a forum
I participate in, and they all agreed that they do not
necessarily consider a 'general' solution to address every
possible need which might arise.
So you are not alone in your woolly thinking. But you present no
evidence that the question asked was applicable, or that the answers
given, if any, are accurately reported here.
So, when I attempt to build a 'general' solution for finding
the position of an object, for example, I'm attempting to
address the majority of typical contexts in which it would be
used. So most people, under most conditions, _could_ in fact
drop the library into their code and have it work correctly.
So abandon describing the result as "general" and assert that the
results are a solution to the problem that you are really trying to
solve.

<snip> If exceptions happen (and they will) then I would hope that
the person finding it would tell me details and provide a
test case so I could determine if the need is typical enough
(in my own opinion) to be included in the general library
and should be fixed, or if their context is so specific to
their situation that they would need to write specific code
for their case.
An unrealistic expectation given your assertion that the developers in
question can be expected to have little understanding of the technology
they are using.
Of course, when people such as yourself claim to find an
exception and refuse to provide details or a test case,
that doesn't help to make the general routine more solid.
In fact, since you refuse to provide any evidence, I'm not
sure I even believe you. It's easy to make empty claims. *shrug*
And listing the CSS properties (most of which are not applicable to IE)
and that the browser in question was IE was not enough for you to
experiment for yourself?
A 'partial solution' is valuable because it solves a
specific case and can be used in a more general solution.
For example, the code using currentStyle to find the style
applied to an object is a 'partial solution' because it
does solve the problem for a subset of all cases. Combined
with other 'partial solutions' they form a more general
solution which is more valuable.
There is a difference between asserting that something is a 'partial
solution' and recognising that it may be part of the real solution. The
problem is not solved until there is a solution.

<snip>
<snip about my 'advertising' and supposed real motivations>


Nothing will change your opinion of my efforts, Richard,
so what I write won't even matter.


My opinion could be changed if you exhibited behaviour that was
inconstant with my beliefs about your motivations. For example, my
beliefs suggest that you will remain unwilling to make a public
statement that answers my previous (and repeated) question as to whether
you believe that the clients of a professional providing technical
and/or design services has a reasonable right to expect that
professional to have an understanding of the technologies they use. A
public expression of support for caveat emptor would not be good PR for
you (or anyone else for that matter).
But, the truth is that when I direct people to my stuff, it's
always because it _specifically_ addresses their needs,
That is just not true. In the majority of the cases I have seen there is
just not sufficient information available for anyone to be in a
po9sition to know the specific needs of an OP, except possibly that OP.
and I think they will benefit from it.
If you took the time to ascertain specific needs then that may be true.
But since you actually promote your code when you perceive it
potentially applicable your motivations seem other than your altruistic
assertions.
I don't advertise.
Posting URLs in signatures of Usenet posts is considered an acceptable
form of advertising (within the recognised limits).
If you have specific code which solves their specific problem,
you may post it. If I have already written a solution which
solves their problem, I may direct them to it.
Without ascertaining what the real specific problem is?
I happen to offset the cost and development time with
donations and google ads, although I certainly do not 'come
out ahead' in the game.
But you would make that claim even if that income represented a
significant contribution to your income, because voluntary contributions
are more likely when the recipient seems altruistically motivated.
People are more willing to give money when they can feel good about
doing so.
If I were trying to make a profit, I would be charging for
my work rather than giving it away with almost no useage
restrictions.
That doesn't follow. Given that when you sell something the purchasers
have expectations about what they get (fitness for the task, support,
ongoing development, etc) and you have to get involved in all the legal
stuff that goes along with running a business (keeping accounts, paying
sails tax, etc) it is entirely possible for a business model based on
voluntary donations to produce greater returns for the effort.
Especially when promoted as an altruistic enterprise where any donations
will act for the greater good.
My goal is to provide solutions which help average web
developers perform complex tasks which they may not be able
to do themselves.
Which brings us back to the point of the 'teach a man to fish' cliché;
helping the average developer to understand how to perform complex tasks
for themselves so obviously is going to be doing them more good in the
long run that questioning your asserted motivations seems reasonable
when you spend your time actively discouraging the 'average web
developer' form even recognising a need to understand what they are
doing.
I get personal satisfaction knowing that I've helped
thousands of people solve their problems
That certainly would be easier to live with than recognising all of the
harm done to clients (and users) by all of the needless and avoidable
introduction of javascript dependencies that will have resulted from
your actions.
when people like you would have told them
that they didn't even deserve to be helped.
Would people like me have told them that?
If
If?
I'm ever seen as 'promoting' my stuff, it's because I want
people to be made aware of packaged solutions which can
solve their problem,
Well, we have seen how imprecisely you identify problems.
rather than being faced with people telling them how stupid
they are,
I only recall one of us asserting that the 'average web developer' was
incapable of understanding what they were doing.
or resorting to finding terrible code at some copy-n-paste
javascript site.
And heaven forbid that anyone should find a pre-packaged 'solution' on a
copy-n-paste javascript site ;)
If you don't believe me, that's fine. I don't care.


Another case where behaviour doesn't appear to correspond with
assertions.

Richard.
Nov 23 '05 #124

P: n/a
Richard Cornford wrote:
'Ideally', yes, that would be nice. Realistically, no. That's not
the goal. The goal would be able to have code which works when
dropped into the majority of typical situations. Then why do you talk about your code being general when you are only
asking it to be braod?


Because we have a difference in terms. By a "general solution", I am meaning
a solution to a more general problem. If you want to call it 'broad' that's
fine.
If they have a case not covered in the generalized solution, they can
provide a test case and ask for the condition to be covered in the
code.

If the person doing the dropping has no technical understanding of
what they are doing then they are unlikely to be able to create a
test case


Don't be so obtuse. Your logical reasoning (or lack thereof) makes you draw
all these incorrect conclusions about statements I've made.

I said one of the goals is for someone with limited technical understanding
of javascript to use the libraries. That does NOT mean that everyone using
them will be in this category. There are certainly very skilled developers
who can build test cases and point out specific flaws who are using these
libraries. And then there are people who can barely write html who drop them
in and use them. The audience is varied, although you want to pigeon-hole
them all into being 'stupid users'.
The term 'general' is relative.

You haven't precluded the possibility of 'general' being an absolute.


I've implied it, if not stated it outright. 'General' is relative.
'Exhaustive' is absolute. Your 'glass' example is pointless.
[snip nit-picking about the problem definition in my posted code examples]
You're just being argumentative. The functions I posted were an example of a
function progressing from less general to more general, in order to
illustrate the point. It was not meant to be a perfectly-stated problem or
perfect solutions. I thought that was obvious.
Again that is not a more general solution to the problem it is a
solution to a more general problem.
Which to me says the same thing.
But what happens if this more general problem cannot be solved? Can
the function that only returns the CSS color property be regarded as a
'partial solution' to this more general problem. We know that it will
return a correct and useful value for a subset of possible parameters.
Would it become a 'partial solution' when that subset became the
majority of possible parameters?
IMO, yes. In the cases where a correct value isn't returned or can't be
returned, it should either attempt to arrive at the values in a different
way or return a consistent result, or at least note the known conditions
where it will not return the correct value.
I don't think that there is such a thing as a 'partial solution', just
poorly identified/defined problems.
Perhaps 'partial solution' is a bad term, I don't know. To me, a 'partial
solution' is a solution which solves the general case for a subset of all
possible permutations, but solves that subset exhaustively. So it's known
that the solution isn't general enough to be used in every context. But when
used in the contexts where it applies, it can be regarded as an exhaustive
solution.
The goal of building 'general' solutions is to provide
functionality that works in the majority of contexts that
arise in typical development.

No, that is the goal of providing functionality that will work in the
majority of contexts that typically arise in development.


Semantics games! I stand by my original statement.
Your insistance that a 'general' solution must be 'exhaustive'
is incorrect (or at least, not the typical opinion).

Typical of who exactly?


The web developers I've come into contact with in the last decade or so.
Shall we do a worldwide poll?
If exceptions happen (and they will) then I would hope that
the person finding it would tell me details and provide a
test case so I could determine if the need is typical enough
(in my own opinion) to be included in the general library
and should be fixed, or if their context is so specific to
their situation that they would need to write specific code
for their case.

An unrealistic expectation given your assertion that the developers in
question can be expected to have little understanding of the
technology they are using.


Again, your erroneous logic assumes that because *some* developers have
little understanding of the technology, then *all* developers must. This is
not the case.
Of course, when people such as yourself claim to find an
exception and refuse to provide details or a test case,
that doesn't help to make the general routine more solid.
In fact, since you refuse to provide any evidence, I'm not
sure I even believe you. It's easy to make empty claims. *shrug*

And listing the CSS properties (most of which are not applicable to
IE) and that the browser in question was IE was not enough for you to
experiment for yourself?


No, because it could be a waste of my (limited) time. I know there are some
quirks in IE, as noted at the top of the page. So if you set an object's
position to 'relative' and saw it fail, that wouldn't surprise me at all,
since I already noted that. I know that other problems may exist. I haven't
fully tested it yet or built enough test cases. That's why it's not
'released' yet, and I'm still gathering feedback.
you will remain unwilling to make a public
statement that answers my previous (and repeated) question as to
whether you believe that the clients of a professional providing
technical and/or design services has a reasonable right to expect that
professional to have an understanding of the technologies they use.
Yes. A professional providing technical services should have an
understanding of the technologies they use.
In an ideal world, that would always be the case.
However, reality is never an ideal case.

For example,

1) You can pay $200/hr for an expert, and you can hire a college kid for
$15/hr. Your expectations about their level of understanding of the
technologies would certainly not be the same in both cases. Sometimes you
don't expect perfect results or great code, because you know you can't
afford it!

2) Someone can pass themselves off as an expert but in fact not deliver
expert results. This is extremely common! A _lot_ of coding is done to poor
standards by supposed 'experts' who actually ship the work off to India or
some group of inexperienced developers.

Furthermore, since my libs are not targeted exclusively at professionals who
should understand the technology themselves, it seems odd to even make this
point. Even if you think that professionals being paid for their work
shouldn't use libraries, why do you also believe that casual developers or
volunteers should also not use them?
But, the truth is that when I direct people to my stuff, it's
always because it _specifically_ addresses their needs,

That is just not true. In the majority of the cases I have seen there
is just not sufficient information available for anyone to be in a
po9sition to know the specific needs of an OP, except possibly that
OP.


Because you don't believe in general solutions, you always require more
information from the OP and specific requirements.
Since I write general solutions, I can reasonably deduce that my solution
will fit the OP's needs without having specific requirements, because I know
it can handle most common cases that arise. If it didn't look like the OP's
situation would fit into my solution, I wouldn't recommend it!
Which brings us back to the point of the 'teach a man to fish' cliché;
helping the average developer to understand how to perform complex
tasks for themselves so obviously is going to be doing them more good
in the long run that questioning your asserted motivations seems
reasonable when you spend your time actively discouraging the
'average web developer' form even recognising a need to understand
what they are doing.


That's an incorrect characterization of my point of view. I will always
encourage people to learn the skills needed to write things on their own. I
would never discourage someone from learning to solve a problem from scratch
to enhance their understanding of it. I just realize that this is not always
practical or necessary in a given situation.
I get personal satisfaction knowing that I've helped
thousands of people solve their problems

That certainly would be easier to live with than recognising all of
the harm done to clients (and users) by all of the needless and
avoidable introduction of javascript dependencies that will have
resulted from your actions.


a) I do plan to write more about the javascript dependencies introduced by
each of my libs as I revamp my site.
b) I do plan to provide more examples which 'degrade gracefully'
c) I don't think that introducing javascript dependencies is a bad thing
d) I don't think your view of the web is in line with every 'intelligent'
developer out there, as you seem to think.
e) If I've done so much harm, why do I not get hundreds of emails a day
telling me so? Oh, that's right, because nobody understands like you do. It
must be rough to be at the top, eh?

I think 'unobtrusive javascript' is a great thing, but I also think that
many sites and developers are happy to require javascript for some
functionality. The need to 'degrade gracefully' is not absolute, as you
imply. There are plenty of contexts where such a need doesn't exist at all.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 23 '05 #125

P: n/a
Matt Kruse wrote:
Richard Cornford wrote:
[...]


Matt, yours was a 201-lines response to Richard's 446-lines response to
your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.
I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?
PointedEars
Nov 23 '05 #126

P: n/a
Thomas 'PointedEars' Lahn said the following on 11/13/2005 11:26 AM:
Matt Kruse wrote:

Richard Cornford wrote:
[...]


Matt, yours was a 201-lines response to Richard's 446-lines response to
your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.


Welcome to Richard, Matt and clj
I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?


Huh? And miss all this fun? You are kidding, right?

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 23 '05 #127

P: n/a
VK
> Matt, yours was a 201-lines response to Richard's 446-lines response to
your 189-lines response to Richard's 146-lines Response, where apparently
the subject discussed is no longer restricted to JS programming but instead
deals with what to call how properly in terms of software development.
I think it is highly unlikely subscribers of this (JS) newsgroup will
benefit from what is supposed to be a 500-lines response from Richard,
and I think we are well beyond the point where the discussion should
move to another, perhaps more general newsgroup, or to private e-mail.
Please, let's call it a thread, shall we?


I guess they are well covered by the foggy thread subject ("Best
practice" can encompass anything). But truthfully I'm enjoying the
matter of this discussion - but yes, it's getting too multiwordy.
Lesser reasonning - more proofs.

Overall as I see it - this is a reflection of two schools: Academic one
that consider JavaScript (or programming at whole) nearly as a way to
the internal perfectness and the right recognition of the world.

The other one takes JavaScript (or programming at whole) as a much more
humble *practical* matter. You may guess what side I am.

About libraries vs. "know everything yourselve" - just a little sample:

I order to make IE's FileScriptingObject to work as documented I had
(including but not limited to):
1. Use Enumerator class wrapper as file/folder collections are not
accessible via for...in loop.
2. Create predefined literals for file operation modes (ForReading,
ForAppending etc.) because Microsoft has documented them but has
forgotten to implement.
3. Make char stream setting monitor to fix double interface glitch for
new files (because expected encoding is set twice independently in the
File object and in the TextInputStream object.

And that was only for Microsoft. I'm just starting with Gesko but I bet
my head against your hat what there will be a bunch of similar
surprises there too.

Why should we force everyone to go throu this process over and over
again instead of using a library?
Why skipping on finding and fixing 3rd party implementation errors
should hurt anyone?

Nov 23 '05 #128

P: n/a
VK said the following on 11/13/2005 1:04 PM:
The other one takes JavaScript (or programming at whole) as a much more
humble *practical* matter. You may guess what side I am.

About libraries vs. "know everything yourselve" - just a little sample:

I order to make IE's FileScriptingObject to work as documented I had
(including but not limited to):


A better question for you would be, other than a good exercise, what
good is a web-based File Manager? Really, the only place its going to
work is on Windows based systems and then Windows has a built in FM that
has more features.

After that, the library is of little use. Except in an intranet
environment where the Win FM is still better.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 23 '05 #129

P: n/a
VK
That's going to be really
<OFFTOPIC>

Randy Webb wrote:
A better question for you would be, other than a good exercise, what
good is a web-based File Manager? Really, the only place its going to
work is on Windows based systems and then Windows has a built in FM that
has more features.
Wrong, because FileScriptingObject is used only for the "IE under
windows" block. Second part implements XPConnect equvalent which works
for all Gesko based browsers on all platform. So the total tested
coverage of jsFileManager will be:
Internet Explorer 5.0 or higher under Windows 98, NT, 2000, ME, XP
Gesko browsers under any platform.
- all by using single constructor call and uniformed interface.

I would say that this coverage is more than satisfactory and it can be
called "universal with few limitations" (a profound examination of the
term "universal" see in this thread :-)

It still will not work but degrade seemlessly on an ancient browser or
say on "myFirstBrowser v0.1" under "KickA**OS v.01.002"
Guess how much should I and do I care?
After that, the library is of little use. Except in an intranet
environment where the Win FM is still better.


Wrong again, because you're missing the whole new big market of
JavaScript desktop applications - what Microsoft tried to push with
their HTA.
No access to file system and limited graphics abilities were the main
reasons it did not start earlier.

Now Firefox comes with SVG native support and VML in Microsoft plus
universal file access module - plus programming environment and
interpreter installed on 99.99% of existing PC's (did you see many PC's
w/o a browser on it?)
Sun with their stupid Java attempts never stayed even close to this.

Again - jsFileManager will work in the same way on both IE and Firefox
(universally - Gesko). Otherwise I would't mention it in this group.
</OFFTOPIC>

Nov 23 '05 #130

P: n/a
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 11/13/2005 11:26 AM:
Matt, yours was a 201-lines response to Richard's 446-lines response
to your 189-lines response to Richard's 146-lines Response, where
apparently the subject discussed is no longer restricted to JS
programming but instead deals with what to call how properly in
terms of software development.

Welcome to Richard, Matt and clj


Believe me, I try not to make it so. Richard is absurdly verbose in most of
his posts here, and to keep anything short and to the point with him is near
impossible. I think he does have valuable insights into some things, and
is - at the very least - a good "devil's advocate" to my points in this
thread. He just types too damn much and argues about details instead of
seeing the bigger discussion sometimes.

I keep posting in threads like this because I think many of the questions
and issues raised are important and interesting to discuss. And they aren't
generally happening in other threads ;)
Please, let's call it a thread, shall we?

Huh? And miss all this fun? You are kidding, right?


Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 23 '05 #131

P: n/a
VK wrote:
The other one takes JavaScript (or programming at whole) as a much
more humble *practical* matter. You may guess what side I am.


Hmmm.... I'm not sure if that helps my case ;)

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 23 '05 #132

P: n/a
Matt Kruse said the following on 11/13/2005 8:39 PM:
Randy Webb wrote:
Thomas 'PointedEars' Lahn said the following on 11/13/2005 11:26 AM:
Matt, yours was a 201-lines response to Richard's 446-lines response
to your 189-lines response to Richard's 146-lines Response, where
apparently the subject discussed is no longer restricted to JS
programming but instead deals with what to call how properly in
terms of software development.
Welcome to Richard, Matt and clj

Believe me, I try not to make it so. Richard is absurdly verbose in most of
his posts here, and to keep anything short and to the point with him is near
impossible. I think he does have valuable insights into some things, and
is - at the very least - a good "devil's advocate" to my points in this
thread. He just types too damn much and argues about details instead of
seeing the bigger discussion sometimes.


I know, and agree with you 100%. Richard is very verbose at times, to
the point of being overly verbose.
I keep posting in threads like this because I think many of the questions
and issues raised are important and interesting to discuss. And they aren't
generally happening in other threads ;)

Please, let's call it a thread, shall we?


Huh? And miss all this fun? You are kidding, right?

Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.


It probably does, never looked for it. This thread actually doesn't
bother me, its informative to say the least.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Answer:It destroys the order of the conversation
Question: Why?
Answer: Top-Posting.
Question: Whats the most annoying thing on Usenet?

Please quote what you are replying to.

If you want to post a followup via groups.google.com, don't use the
"Reply" link at the bottom of the article. Click on "show options" at
the top of the article, then click on the "Reply" at the bottom of the
article headers.

Nov 23 '05 #133

P: n/a
Matt Kruse said the following on 11/13/2005 8:40 PM:
VK wrote:
The other one takes JavaScript (or programming at whole) as a much
more humble *practical* matter. You may guess what side I am.

Hmmm.... I'm not sure if that helps my case ;)


With VK's past here, it doesn't help it any :)

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/
Nov 23 '05 #134

P: n/a
Matt Kruse wrote:
Randy Webb wrote:
Please, let's call it a thread, shall we?

Huh? And miss all this fun? You are kidding, right?


Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.


That is a very old argument which has been refuted very often already.

Firstly, what you post has to be distributed throughout the world, from one
NetNews peer server to another, according to the decentralized structure of
Usenet; it is consuming resources many provide for free to keep the medium
running.

Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?

You are wasting precious bandwidth if you post something that is only to
value for two people. (And before one of the trolls around here starts
blathering: I try to continuously remind me of that important fact,
however I am not perfect either.)

Please don't get me wrong: I think your dispute, even in all its length,
is valuable in terms of semantics, maybe software development. However,
I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.
PointedEars
Nov 23 '05 #135

P: n/a
Thomas 'PointedEars' Lahn wrote:
Firstly, what you post has to be distributed throughout the world,
from one NetNews peer server to another, according to the
decentralized structure of Usenet; it is consuming resources many
provide for free to keep the medium running.
That's an absurd argument, given the quantity of news that gets distributed
daily.
Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?
I was just pointing out a convenience feature which you or others may not be
aware of.
You are wasting precious bandwidth if you post something that is only
to value for two people.
I disagree. I think the bigger issues being discussed are valuable to many
others. When Richard makes it personal, I try to [snip] those parts out and
not even respond.
Please don't get me wrong: I think your dispute, even in all its
length, is valuable in terms of semantics, maybe software
development.
Semantics certainly is not something I care to debate, and the bigger issue
of software development is something I'd like to steer away from also.
However,
I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.


Well, I disagree. Much of the discussion is specific to javascript - dealing
with generalizing methods for different contexts and browsers, delivering
extra code to the browser, dealing with different skill levels of javascript
developers, and the merits of a library approach to solving problems.

I agree that this thread has become a bit tiresome, but I think that could
be avoided with shorter more concise posts and less nit-picking about minute
points while ignoring the general issues.

It is the nature of newsgroups to have many posts and topics which do not
interest you personally. That's why I recommended using a newsreader with a
feature to ignore entire threads. I would imagine that anyone who grew tired
of this thread would have zapped it long ago and wouldn't even be bothered
by this off-topic discussion we're having now.

To continue this really _would_ be off-topic, so I'll try to keep responses
only to js-related posts from now on...

--
Matt Kruse
http://www.JavascriptToolbox.com
http://www.AjaxToolbox.com
Nov 23 '05 #136

P: n/a
Thomas 'PointedEars' Lahn said the following on 11/14/2005 5:16 PM:
Matt Kruse wrote:

Randy Webb wrote:
Please, let's call it a thread, shall we?

Huh? And miss all this fun? You are kidding, right?
Do your news readers lack the ability to ignore an entire thread so you
don't even see it? I use it regularly, even in this newsgroup.

That is a very old argument which has been refuted very often already.


What argument? That you, as the reader, control what you do or do not
read? That is precisely why NewsReaders have killfile's in the first place.
Firstly, what you post has to be distributed throughout the world, from one
NetNews peer server to another, according to the decentralized structure of
Usenet; it is consuming resources many provide for free to keep the medium
running.
Every post in every thread in this group (and all other Usenet groups)
have to be propogated also. This thread is not even making a slight
dimple in the resources used to keep Usenet running.
Secondly, how dare you imposing your perception of a viable newsreader
on others just to satisfy your personal quarrel?
And in the same token, how dare you attempt to impose your perception of
a timeframe for the end of a thread? You control what you do or do not
read, use that control.
You are wasting precious bandwidth if you post something that is only to
value for two people. (And before one of the trolls around here starts
blathering: I try to continuously remind me of that important fact,
however I am not perfect either.)
You are assuming that it is of value to only two people. Just because
only two people are posting to the thread does not mean other people are
not reading/gaining from the thread.
Please don't get me wrong: I think your dispute, even in all its length,
is valuable in terms of semantics, maybe software development.
It has value, to me anyway, in terms of WWW scripting.
However, I fail to see any value in it regarding JS/ECMAScript programming
_specifically_ which is why I consider it to be off-topic in _this_
newsgroup.


If you search these archives for CSS only, HTML only, and non-JS
solutions, the number of posts you find will be far far greater than the
posts in this thread. The point is, there are a ton of off-topic threads
in this group that take up a lot more resources than this one ever will.

If you don't want to read it, killfile the thread. Then, you are saving
your bandwidth, you are not adding to the bandwidth usage, and everybody
moves on.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/

Nov 23 '05 #137

136 Replies

This discussion thread is closed

Replies have been disabled for this discussion.