Re: Javascript Best Practices Document v1.0
- From: "Richard Cornford" <Richard@xxxxxxxxxxxxxxxxxxx>
- Date: Mon, 31 Oct 2005 21:32:44 -0000
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/ObjectPositionTest.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.
.
- Follow-Ups:
- Re: Javascript Best Practices Document v1.0
- From: Matt Kruse
- Re: Javascript Best Practices Document v1.0
- Prev by Date: Re: Background colors don't appear in IE 6
- Next by Date: Re: Background colors don't appear in IE 6
- Previous by thread: Re: Background colors don't appear in IE 6
- Next by thread: Re: Javascript Best Practices Document v1.0
- Index(es):
Relevant Pages
|
