It seems to me that attempting to enforce types to catch programming errors
misses a bit of the point of Javascript. I suppose it would make certain
methods of debugging simpler at the cost of greater code complexity, but
that benefit seems to be less than overwhelming to me.
Perhaps it's related more to my Javascript style, but I really don't run
into type errors often enough for me to consider this necessary. I can see
it being useful for people who primarily work in statically typed
languages,
though I feel it would be better in the long term to learn
language-friendly ways of handling the situation (like common property
names, discipline about object ownership, and proper encapsulation).
I agree that the dynamic typing nature of Javascript is what makes it useful
and suitable for certain tasks. I also agree that not everyone will benefit
from type verification as most webpages are simple and Javascript only
serves as a complementary technology (like autocomplete) where type
verification may be an unnecessary restriction. But with large-scale AJAX
applications where code complexity is inevitable and where many parts of the
webpage are generated and driven with Javascript, it is precisely this
dynamic typing nature which makes debugging harder, and where type
verification would be beneficial.
For example, in my project people have mistakenly passed the wrong objects
around (they didn't read the docs) and the errors were not detected because
these objects used similar property/function names. In a recent GUI example,
we have a function which will process a SubMenu object by calling
SubMenu.open() and then passing it position offset information. But some
people were mistakenly passing it the MenuItem object instead (which
contained the SubMenu) which called MenuItem.open() which still opened the
menu, but then passed the wrong position information. People didn't
understand why and assumed that because open() was called, they wrote
everything correctly (which is generally true in our trial-and-error
society). In the end we enforced the parameter with an instanceof check
which allowed the programmers to catch errors early.
Also, in this example:
function showMenu(obj) {
if(obj instanceof MenuItem) {
obj.getNode().style.visibility = "visible";
} else throw new Error("Invalid parameter!");
}
it would be better to hide the visibility changes behind a method on the
MenuItem object. Objects should always take care of themselves.
Yes, I wasn't thinking particularly hard when I came up with this example.
Perhaps I thought illustrating a few DOM manipulations would give it more
web-mojo. Or what if the object was deliberately exposing the node to allow
for a "decorator" design pattern in determining how the menu is shown?
... Also, when you call the method, if it doesn't exist on the object,
you'll get a language error which is essentially the same error your code
produces, without doing any extra work.
With function invocation, yes, but with property assignment, no. If my
particular implementation were used, it would catch both. I guess I would
have been better off throwing an error instead.
I apologize for turning this into a screed, I spend a lot of time at work
trying to teach the zen of object programming.
No, I love these discussions and am continuously learning new things.
On 7/28/06, Hill, Greg <[EMAIL PROTECTED]> wrote:
> Yes, it is used to catch programming errors by introducing a little
type
> safety. How many times have you written this in your project:
>
> function showMenu(obj) {
> if(obj instanceof MenuItem) {
> obj.getNode().style.visibility = "visible";
> } else throw new Error("Invalid parameter!");
> }
>
> Now you can just do this:
>
> function showMenu(obj) {
> MenuItem(obj).getNode().style.visibility = "visible";
> }
>
> This convention just makes codifying assertions a little more
[truncated]
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
