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).
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. Exposing a contained element is typically going to bite you later when you don't know where all your manipulations are occurring. 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.
I apologize for turning this into a screed, I spend a lot of time at work trying to teach the zen of object programming.
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 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
_______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
