On 12/28/2010 11:49 AM, Adam D. Ruppe wrote:
Let me tell a horror story about what is definitely bad modularity:
something that happened in the old PHP app.
(I might pick on PHP a lot, but that's just because it is the
language I have the most professional experience in so I've seen
a lot of its horrors first hand. That, and it is a godawful language!)
So I had to add a function to one of the project's includes to enable
new functionality. I didn't even get very far into it before a
mysterious error came up across the site:
PHP Fatal error: Cannot redeclare bar_foo() (previously declared
in my file) in completely unrelated file on line x.
WTF. I coincidentally picked the same name for my function
as my predecessor did for another function a long time ago, in
a file far, far away! And it broke things scattered throughout
the program. C does this too, but at least there's a compile
step to save you.
The sad part: that's the best case scenario with PHP! If it hadn't
broken the entire site, I might not have caught it so early and
then there'd be a real mess on the one page that just happened
to include both files at once, hidden, lurking...
But hell, at least if you coincidentally pick the same name as
your predecessor it doesn't *overwrites* one of your functions at
runtime like some languages! I kid you not, some popular languages
actually do that. It blows my mind.
Anyway, that's bad modularity and a couple of bug prone behaviors
coming from it. Using a strict naming convention with long, fully
qualified names (like familyname_functionname convention) might
be a good thing in those languages, to reduce the odds that two
team members pick the same name and break code elsewhere in the app.
In D, however, such things are not necessary. The compiler makes
it Just Work or fail early and fail meaningfully in the exact
place where there actually is a problem and nowhere else. Such
problems cannot occur, so the logic that goes into protecting
yourself in other languages don't necessarily apply to D.
This actually reminds me of an article I read quite a while ago that
praised Erlang for how it handles functions in different modules. It
requires that you prefix the name of any function that is imported with
the name of the module you are importing from. So, if you want to use
the function bar from module foo, you write something like this:
foo:bar(1),
Now, the nice thing about this is that you immediately see what module
this function came from. Also, it helps ensure that your function names
are truly unique since they now include the module name. However, the
bad part is that you have more to type. Personally, I find that to be a
minor issue compared to the benefits, but that's just me.
Am I saying this is how it should work in D? No, but I think it can be
done now anyway if IIRC. I'll have to look at the docs. Regardless, it
may be a good "best practice" for those times when you are working on a
large application.
Casey
