I know some people are arguing but I love seeing the code examples. Personally I may just not understand fully what object-oriented means, but I always felt you -can- code GM in very object oriented ways and I think
@Fel666 demonstrates a very interesting version of that. I mean, instances themselves cannot 'speak to' or touch one another inherently, you have to code in such a way that becomes a possibility. So if you want private or restricted variables you simply have to code in such a way that instances either don't have access to each other, or when they do -you- are responsible for not making them interfere with each other's vital functions. It reminds me of something I read a while back, and I wish I could remember the quote correctly but it was along the lines of companies hire mediocre programmers and utilize object-oriented structures to minimize the negative impact any of them can have.
Whether or not that's true, what IS true is there is no substitute for good coding habits. If you make two objects dependent on each other, it's not GMS' fault, it's yours for building a program like that. And GML like any language has it's own best practices and pratfalls. Coding in safeguards isn't really a solution, improving your understanding of the language and program structure is. The only real rule I use for coding in GML anymore is that nothing supporting another object should rely on it. My UI elements might rely on my GUI handler, but it runs whether or not they exist. If you build that way, you can both safely add and remove elements without worrying about creating bugs or breaking parts of the program. To me, that's the essence of object-oriented programming and it's completely feasible within the scope of what GameMaker provides.