The SitePoint Forums have moved.

You can now find them here.
This forum is now closed to new posts, but you can browse existing content.
You can find out more information about the move and how to open a new account (if necessary) here.
If you get stuck you can get support by emailing forums@sitepoint.com

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Simple Javascript Calculator

Hi

I have a project that I have to do for uni in which I have to make a simple calculator in Javascript. It must let you enter 2 numbers then give the user the chance tho decide whether the numbers are added, subtracted or multiplied. So far I have managed to have three different functions with three different buttons and this works. I am however trying to get it to work so that the user could enter the sign in a text box and then click on one button to perform the calculation as this gets better marks. I am totally stumped on how to do this with just one function and is it possible?

If by that you mean that we should be giving hints rather than resolving a request, then I've misunderstood the point of this forum. I'm not sure why you think it has to be long-winded. Dtennant9 asked for a way to minimize the code. That's what I've offered.

My point is, that if someone comes here for help with school, a solution should not be handed to them.

Well I'm here to answer, not to tutor

Originally Posted by beetle

And eval() isnot a more efficient way of coding. It's more brief, but that's it. Brevity and efficacy are not always the same thing.

Agreed, but I'm fairly sure that in this case they are. There is no conditional branching and no redundant code as far as I can see. I'm happy to be proved wrong however if it means that I can improve my coding in future.

Originally Posted by beetle

There are times and places to use eval(), but it's not something easily understood, therefore best avoided until that knowledge is attained. That's why I never recommend eval() to newbies.

Really? Maybe it has hidden depths, but I thought it did exactly what it said on the tin

Well I'm here to answer, not to tutor [img]images/smilies/wink.gif[/img]

That's fine. But an answer doesn't have to be a solution. All I'm asking is to be mindful of students and the value of learning in the future. dtennant9 is much better off learning control structures than eval().

Originally Posted by awestmoreland

Really? Maybe it has hidden depths, but I thought it did exactly what it said on the tin

Yes: to both. First of all, it's the single most costly (overhead-wise) function in javascript. Secondly, it jiggers the scope chain -- a concept too advanced to explain to newbies, so again, it's just best avoided until understanding is possible. Remember, eval() is not a portable skill, but things like control structures and hashtables are.

Originally Posted by awestmoreland

Agreed, but I'm fairly sure that in this case they are. There is no conditional branching and no redundant code as far as I can see. I'm happy to be proved wrong however if it means that I can improve my coding in future.

In this case, yes, they are the same. But that's not the point. Code efficacy comes in many flavors, and semantics are always important. You can improve your JS coding in other ways:

I really wish that one of the brainboxes around here would invest some time in sorting out the bug that makes code look like that

I can see what you've done there within the function (and by calling it referencing "this.form") however I've always shied away from that in the past. Surely by the end of your function, you're dealing with constructs which equate to things such as "form.operator.options" and "form.result.value" which seem more IE4 than the constructs that I had using getElementById?

First of all, you run document.getElementById4 times. Methods are always more costly than property lookups. Secondly, you run document.getElementById twice for the same element. Storing a reference is much better for something like this, I even mention that in my post at the tips thread.

We are only concerned with two processes.

1) Obtaining references to the form elements
2) Getting or setting their value property.

#2 will always be the same. Therefore, all our optimizations must be with step #1. Referencing a form's elements via either the elements collection or the exposed form properties that all modern browsers provide, is faster and cleaner than the top-down approach using document.getElementById. Not to mention more compatible, since document.getElementByIddoesn't work in IE4, whereas my solution will.

BTW, the forum software replaces every 4 spaces with a tab, and every tab with a single space. Kinda annoying.