|
|
Posted by ^reaper^ on 07/09/05 13:54
While sipping absinthe, Michael Winter heard a loud sucking noise coming
from alt.2600,alt.html,alt.php, and hastily inscribed the following
unintelligible Sanskrit in
<news:12vze.65588$G8.6372@text.news.blueyonder.co.uk>:
> On 08/07/2005 12:05, ^reaper^ wrote:
>
> [snip]
>
>> Or, for example, say you want to reference a document object that
>> contains a variable component, you can do something like this:
>>
>> eval('document.all.'+name+'.style');
>
> Even then, it's not necessary:
>
> document.all[name].style
Well, um, yeah. I did point that out. Or did you miss this bit?
>> though, this:
>>
>> document.getElementById( name ).style;
>>
>> would accomplish the same thing.
No matter. That I know of, the choice of which of the above to use is
purely dependent upon browser and version. Though the browsers have been
converging wrt dom standards, so the document.getElementById appears to
work in the majority of cases.
> The eval function is best left for /arbitrary/ strings that need to be
> evaluated as code. However, it is very rare that one will ever have such
> a need.
True. It also tends to add a level of complexity that can potentially
obscure the underlying logic.
> The only use I've found so far is for emulating the
> Function.prototype.call or apply methods in (mainly) earlier IE
> versions. Unlike the dynamic construction of property names, there is no
> other way of building an argument list at run-time without the use of
> the apply method.
>
> var global = this;
>
> if('function' != typeof Function.prototype.apply) {
> Function.prototype.apply = function(o, a) {
> var x = [],
> p = ' $apply',
> r, u;
>
> if(null == o) {o = global;}
> while('undefined' != typeof o[p]) {p += p;}
> o[p] = this;
>
> if(a && (Array == a.constructor) && a.length) {
> for(var i = 0, n = a.length; i < n; ++i) {x[i] = i;}
> r = eval('o[p](a[' + x.join('],a[') + ']);');
> } else {
> r = o[p]();
> }
> o[p] = u;
>
> return r;
> };
> }
So, basically, you /could/ end up with:
some function o[p]( a[0],a[1],a[2],...a[n] );
Though I'm uncertain why one might wish to create such a function on the
fly. As the calling statement must also know the arguments required for the
function. Otoh, if you're attempting to mimic a factory, I guess. o_O
> Still, even that has a slight problem. Though IE will set the this
> operator value correctly for a null or undefined first argument, this
> value will not compare properly to the global object.
>
> All that said, given the fact that one usually knows how many arguments
> will be needed in a call to one of these methods, this form of generic
> emulation is rarely needed.
>
> I have seen other interesting uses for the eval function, but even they
> weren't really necessary.
I'm not sure what you mean by unnecessary. After all, there are generally
several ways to implement code. And outside of gross coding practices
(e.g., extensive use of globals and for-loops, to name but a couple), the
tradeoffs are (or should be) the primary factor in the final decision.
But anyway, here's one for you.
:var period = new Array(
: new MyObj( 'years','this.per * 12' ),
: new MyObj( 'semi-annual',"this.per / 2' ),
: new MyObj( 'quarters','this.per * 4' ),
: new MyObj( 'months','this.per / 12' ),
: new MyObj( 'days','this.per * 365' ),
:)
:var calcs = new Array(
: new MyObj('fvLumpSum','pv*(Math.pow((1+r),nper))' ),
: new MyObj('fvAnnuity','pmt*((Math.pow((1+r),nper)-1)/r)' ),
: new MyObj('fv','eval(eqn[0].eqn) + (eval(eqn[1].eqn)*( 1+r*ltype ))' ),
: new MyObj('arGrad','g*((Math.pow((1+r),nper)-r*nper-1)/(Math.pow(r,2)*Math.Pos((1+r),nper)))' ),
: new MyObj('arGradPW','g*((Math.pow((1+r),nper)-(r*nper)-1)/(Math.pow(r,2)*math.pow((1+r),nper)))' ),
: new MyObj('geoPW','A*(nper*Math.pow((1+r),-1))' ),
: new MyObj('geoPWnG','A*((1-Math.pow((1+g),nper)*Math.pow((1+r),-nper))/(r-g))' ),
: new MyObj('projRate','Math.log(mult)/Math.log(1+r)' )
:)
:function MyObj( nm, eq ){
: this.name = nm;
: this.eqn = eq;
: this.per = 0;
:}
:function calculate(){
: var r = parseFloat( document.all['rate'].value ) / 100;
: var pv = parseFloat( document.all['principal'].value );
: var pmt = parseFloat( document.all['payment'].value );
: var interval = document.all['interval'].selectedIndex;
: var kind = document.all['kind'].selectedIndex;
: var g = document.all['guess'].value;
: period[interval].per = document.all['calcs'].value;
: var nper = eval( calcs[interval].eqn );
: document.all[period[kind].name].innerText = eval( calcs[kind].eqn );
:}
As you can see, the above is quite simplistic. This example btw, was born
out of a discussion involving an original 200+ line script that was
primarily if-then-else ad nauseum. Even in light of this rendition, wherein
I am modeling a macro-like scenario, there is no doubt a more efficient way
to implement the solution. And yes, I'm old school, so I tend to favor
macros. Unfortunately, unlike compiled langs, we don't have the benefit of
true macros (which are inlined at compile time). Nonetheless, rather than
completely giving away the store here, I'll let you ponder this a bit of
code, and even attempt to guess, if you wish, why I may have chosen the
route that I did... my favoritism of macros notwithstanding. ^_~
--
"God split himself into a myriad parts so that he might have friends" --
'The Notebook of Lazarus Long,' Robert Heinlein
Navigation:
[Reply to this message]
|