Simulating aspects of static-typing in a duck-typed language

Posted by Mike on Stack Overflow See other posts from Stack Overflow or by Mike
Published on 2010-05-29T01:50:40Z Indexed on 2010/05/29 1:52 UTC
Read the original article Hit count: 560

In my current job I'm building a suite of Perl scripts that depend heavily on objects. (using Perl's bless() on a Hash to get as close to OO as possible)

Now, for lack of a better way of putting this, most programmers at my company aren't very smart. Worse, they don't like reading documentation and seem to have a problem understanding other people's code. Cowboy coding is the game here. Whenever they encounter a problem and try to fix it, they come up with a horrendous solution that actually solves nothing and usually makes it worse.

This results in me, frankly, not trusting them with code written in duck typed language. As an example, I see too many problems with them not getting an explicit error for misusing objects. For instance, if type A has member foo, and they do something like, instance->goo, they aren't going to see the problem immediately. It will return a null/undefined value, and they will probably waste an hour finding the cause. Then end up changing something else because they didn't properly identify the original problem.

So I'm brainstorming for a way to keep my scripting language (its rapid development is an advantage) but give an explicit error message when an an object isn't used properly. I realize that since there isn't a compile stage or static typing, the error will have to be at run time. I'm fine with this, so long as the user gets a very explicit notice saying "this object doesn't have X"

As part of my solution, I don't want it to be required that they check if a method/variable exists before trying to use it.

Even though my work is in Perl, I think this can be language agnostic.

© Stack Overflow or respective owner

Related posts about perl

Related posts about language-agnostic