> 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 uniform.
You
> know for sure that the parameter is of the correct type because (a) if
it
> isn't it, will be converted to the correct type; and (b) if it cannot
be
> converted, it will throw an error. This allows you to quickly detect
and
> correct bugs in your code and allows others (whom use your library) to
> detect bugs in their code.
I have to admit I didn't read the full original email, and the intention
wasn't clear to me. With this one, I now see what you're getting at,
and it seems like a cool idea to me. The only concern I'd have is that
the syntax isn't immediately clear to someone unfamiliar with the code.
It might be better to have a 'cast' class method or something:
MenuItem.cast(obj).getNode().style.visibility = 'visible';
Having it be a dual-purpose constructor might confuse people. Or maybe
it wouldn't, I dunno. Just some thoughts.
Greg
_______________________________________________
Rails-spinoffs mailing list
Rails-spinoffs@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
