Cascading Simple Bugs!

Today was one of those days... I happened to notice a silly little issue with the compiler a few weeks ago that I wanted to tackle: you can have a class and a module with the same name at the same namespace level and the compiler won't flag it as an error. Seems like a small bug, especially given the fact that modern incarnations of the IDE won't allow you to get into this state. However, since older IDEs seemed to have allowed it at one point, and RBScript has no way to prevent it, I wanted to make an error for it.

Famous last words: "it's simple!"

My first pass at fixing the bug actually caused massive problems. You couldn't compile any projects that contained windows or menu bars. I found that to be very odd, because those should still be legal. If you recall from previous discussions, they're a bit odd in that they're actually a module with an inner class. This particular problem lead me on a deeper tour through the code, and I found out that a fairly old subsystem of the compiler was doing more work than it probably should. Asking the root namespace "can you find something with this name" was searching the root namespace, and if it didn't find anything, it would search for modules containing global members! Oops, so that's why my fix hadn't worked.

This got my cognitive wheels spinning. What would happen in the case of classes declaring types, since that's a new feature of the compiler. What should happen with this code:

Module Test

  Global Class Test

    Public Structure Wahoo

      i as Integer

    End Structure

  End Class


  Public Structure Wahoo

    s as String * 10

  End Structure

End Module

Dim t as Test.Wahoo

Contrary to what you might think, this code could actually be unambiguous. It's easy to explain why, and scales well with the concept of importing namespaces: the compiler could prefer a fully-qualified namespace to an imported namespace. In this case, Test.Wahoo is a fully-qualified identifier. If the user wanted the class' namespace, they should use Test.Test.Wahoo instead. However, I'm not 100% certain that's the route I want the language to go. We want to discourage people from polluting the global namespace, and this is rather contrary to it. Still deciding...

However, this lead me to my next "bug." It turns out that you cannot use the fully-qualified name to get the class' structure. In fact, you can't get to it at all! This bug turns out to be another incarnation of the first one -- the lookup code was doing too much work. In the case of Test.Wahoo, it would find the module's structure and work. But in the case of Test.Test.Wahoo, the lookup for Test.Test would fail!

So while looking into fixing that bug, I found an even more scary problem -- the implications from having a window be comprised of a module and a class. Armed with the knowledge that we want to prefer qualified namespaces, check this code sample out:

Module Window1

  Global Class Window1

    Public Shared Sub Foobar()

    End Sub

  End Class


  Public Sub Wahoo()

  End Sub

End Module

Window1.Foobar

That code is essentially what you'd get when adding a shared method to a window in the IDE. However, it's relying on the current implementation details of the compiler to work. Were I to fix my previous example (so that Test.Test.Wahoo would work), it would break this example! Even if we solved the problem by implementing classes within classes (which would allow us to rewrite the underlying window code), we'd still break existing code that is similar to the way our window code works. I just think there's a lot less of that out there than people who use windows and menubars!

Really, what needs to happen is that the entire mess we call a namespace search needs to be cleaned up. The code: Test.Test.Wahoo should really be returning sets of information that are handled once the entire expression is complete, because that's the only time we can tell what the user really means. In the case of Window1.Foobar -- if Window1 was determined as we parsed it, it could refer to the module or the class, depending on what we find to the right of the ".". In this case, we find Foobar, and so it's clear the user's intention is to call the method on the imported Window1 class. But if we found Wahoo instead, then it's clear that the user intends to call the fully-qualified name for the module's method. The only time it'd be ambiguous and require the user to be more explicit should be if the import causes a naming conflict. But without the concept of lookup sets, that cannot happen. (Sorry, this is looking more and more like a note to myself!)

Basically, there's a few things to take away from this ramble:

1) Global sucks, don't use it. If you have to, be careful not to conflict with existing names at the root namespace because there are problems with it. These problems are not yours (they're mine), but they're likely to exist for a while still. The solution may be to explicitly allow it, or to explicitly disallow it. So until then, work at your own risk!
2) In RBScript, don't name classes and modules the same things at the same namespace level. It's a bad idea, and don't shoot yourself in the foot just because the compiler lets you. Again, my problem, not yours. Just telling you what to watch out for!
3) The next time you find yourself saying "that should be easy for RS to fix", take a step back and realize that REALbasic is an incredibly complex piece of software and we work extraordinarily hard to make it stable, sensible and retain compatibility with older projects. Sometimes "simple" is really hard!