Clay language

[sybrandy]

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