Why everything in a global namespace sucks

Alternatively – why Xojo should put everything in a Xojo namespace and NOT make anything global

I have a few projects that are the results of many many years of coding.

Updating them to the very latest version of Xojo ends up with lots of conflicts since Xojo added a String module with their own global extends for EndsWith and many others that have existed in other peoples code for years.

And, since Xojo didnt add both an extends version AND a non-extends version I have to go adjust all my code because they decided to take over that name. EndsWith is just one example of this. All in all I have about 15000 items like this to go deal with.

And every time I update to a newer version of Xojo, since everything is always in a global namespace, ANY update of Xojo _may_result in many more conflicts like this.

And this taking over of names users may already have used is the problem with a framework that has everything only as extends and always global. Every update may take more of the names you have used for however long and force you to rename and update your code IF you want to keep using code that you may have no reason to want to update.

While I get the syntactic sugariness of the dotted methods names – its hose dotted names that cause this as they MUST be global.

If Xojo had named their module String AND made the methods in string protected then you could always unambiguously refer to yours AND theirs and never have confusion.

Thats not what they have chosen to do and so now we, the users, may end up having to adjust our already working code every time Xojo decides they want to take over another name for some extra functionality.

One Reply to “Why everything in a global namespace sucks”

  1. I’m actually fine with that. More power in Xojo out of the box. But should EndsWith not only have the same name but the same result? Meaning users can delete their version, or restrict it to older Xojo versions?

Comments are closed.