Posted by ^reaper^ on 07/11/05 06:36

While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600, and hastily inscribed the following unintelligible Sanskrit
in <news:BohAe.67140$G8.28999@text.news.blueyonder.co.uk>:

> On 10/07/2005 16:37, ^reaper^ wrote:
>
> [snip]
>
>> The point *was* you accomplish the same end result. Obviously the
>> approach is differnt. One does not even need to know js to see that.
>
> But people less familiar with ECMAScript wouldn't associate one with the
> other unless they were shown side-by-side, which was why I did it. It
> wasn't for your benefit. :)

Ah, but grasshopper. I am not really familiar with ecma. I jest pretend to
be on teh juicenet. ^_~

>> The primary question is, does the browser support it? [...]
>
> Of course.
>
>> if( document.getElementById )return document.getElementById(name).style;
>> else if( document.links )return document.links[name].style;
>> else if( document.all )return eval('document.all.'+name+'.style');
>
> If you do still use that code, you should swap the order of the links
> and all collection branches (as well as replace the eval call). Whilst
> IE does support the links collection, you cannot use strings as indices
> so you shouldn't allow it to reach that statement. That said, only IE4
> would get that far (IE 3 doesn't implement the all collection), so it's
> clearly not a concern if you don't care about something that old.

Yep, I still have that code laying around, fighteningly enuf. Though... I
quit attempting to support xbroswer compat quite some time ago. No matter.
It's a bit from something I threw together in the way back when I was
attempting to support netscape, IE, and AOL's pos browser. And once
something works, while I may reuse it, I tend not to revisit it wrt
revisions, corrections, etc. At least, not for my hobby sites. But thanx
for the pointers. At some point, I'll make the changes to see if I can
break my sites. ^_~

> [snip]
>
>>> The alternative to this is to create a large switch statement with each
>>> clause containing a separate function call with a finite number of
>>> arguments. [...]
>>
>> Why not simply set the function to accept an array argument?
>
> That's a possible solution if you have control over the called function,
> as is using an object.

Hmm... okay. I'm not particularly familar with all of the things you do in
your code (http://www.spyderware.net/source/dynfc.js). Though, both you and
Richard have provided some excellent food for thought. And in fact, I now
have some ideas percolating (teh horrors!) wrt a problem I've been
attempting to solve for one of the compents on my spyderware site.

> [snip]
>
>>> Well, part of it seems to be missing [...]
>>
>> There is no "full code." It was nothing more than speculation in response
>> to other psoted code. Though, I did upload both example snippets (as per my
>> response to Michael).
>
> I'm Michael. He's Richard. :P

Oops! Sorry about that!

> I did find that thread when looking for the original post, but it's a
> bit difficult when you don't allow your posts to be archived. ;) Noodles
> also seems to have removed his page.

Well, if I didn't kill him with those prefabbed eqns, perhaps he'll be
compelled to jump in to this convo. At which pt he can slap me up teh side
of teh head for bastardizing his idea. ^_~

> There's a vast amount of redundancy in the original code, and from what
> I remember, that's almost entirely due to the markup with which the
> script is supposed to interact.
>
> For instance, rather than using groups of radio buttons to determine
> over what period the input relates, he seems to have used individual
> checkboxes, giving the impression that one must check each one,
> producing that massive if..else statement.

I would not be surprised. I actually didn't take a look his page. I simply
reacall his challenge, taking a look at teh code he psoted.

> As for your code, it is a vast improvement, but it still has its own
> redundancy.

This is teh part where you're sposed to say, "That's not code. That's just
a bunch of letters slapped together to masquerade as code.' ^_~

> The functions all set the output themselves. It would be better if they
> returned the value, not only because writing the output would occur in
> one place, but it also shouldn't be the responsibility of that
> particular code to perform any kind of I/O.

Furthermore, if at a later date, you decide to change it, you risk the
possibility of missing something. That, and the general overhead of
maintenance issues. Which is the primary negative about redundancy in the
first place. Which btw, is why I tend to favor macros when it comes to
executing a single, yet complex, expression.

> The statements within each clause of the switch statement only really
> differ in three ways: multiplication versus division; where the data
> comes from; and what arguments are passed to the calculation function.

Hehe. Well, I just made that up (e.g., pulled it out of my.. erm... teh
air). The primary goal was to take into consideration noodles comment that
not all periods were multiplicative. So I arbitrarily threw in a few divs.
In fact, I wouldn't even be able to tell you whether teh calcs (e.g., pv,
annuities, etc) worked, as I'm not a financials type. I simply found some
financial eqns on teh interweb and converted them to js.

> As I don't like code duplication, I'd probably have the data retrieval
> code (for want of a better expression) execute whether the data was
> needed or not. The execution time would be marginal anyway. As you'd now
> have all of the data, you could just homogenise the interface to each
> function and pass the lot. I don't really like that idea though, but
> changing the scope of the functions isn't any better, either. The final
> issue is also awkward. Perhaps the data could be normalised, or the two
> functions that are called later could take the reciprocal of the
> relevant argument.

Yep. Thought of that, though I tend to not like passing in unnecessary
data. Even so, I must admit, I quite like Mi^H^H Richard's implementation.

> [snip]
>
>>> alt.2600 remains cross-posted purely for your benefit, and perhaps that
>>> of OMH.
>>
>> You wouldn't want teh /Guru/ of teh interweb to miss out on this, would
>> you?
>
> Guru? You are still talking about OMH, right?

What? You didn't know he claims to be teh /Guru/ of teh interweb and on teh
/bleeding edge/ of technology. Though, some may argue he is quite correct
regarding teh latter. *snicker*

>> Though... you *do* realize he's a t0rll, right? o_O
>
> Of course. He might not be courteous, but I am (usually). :)

Hehe. Well, spend a bit more time in this froup, and you may get teh hang
of it yet. ^_~

--
"Thus the metric system did not really catch on in the States, unless you
count the increasing popularity of the nine-millimeter bullet." -- Dave
Barry

[Back to original message]