Existing method in module (mostly) disappears when you mark it shared

bgrommes

Summary

I had a module that contained a completed method. I wanted to mark it Shared. When I did so, the method name remained in the toolbar on the left but the editor disappeared and clicking on the method in the toolbar does nothing. The method code and definition became inaccessible.

I shook it loose by duplicating the offending method. The duplicate had all the code, etc., and at that point the original method became visible and interactive again (and was marked Shared), so I deleted the duplicate.

This raises a question. I am struggling a little bit with the purpose of Modules vs Classes.

I first encountered Modules in VB.NET, and I presumed they were a backward compatibility feature to accommodate legacy code from previous versions of VB that lacked OO features. So I basically ignored them I guess. Or at least I don't remember using them.

With Objo, I have come to regard them as sort of a substitute for static / shared classes, yet, that's not quite right either because you aren't obligated to mark all methods Shared. So -- are they implicitly shared? If so then the Shared checkbox should not even be present, or arguably should be pre-checked and greyed out. If not, then why exactly would I declare a Module vs a Class again? Sorry to be dense about this ...

Objo Studio Version

26.7.1

Operating System

Select the operating system(s) affected as tags for this post.

Steps To Reproduce

Expected Result

Actual Result

Screenshots, Logs, Or Sample Project

Garry

Thanks for the detailed report. You’ve uncovered two related Studio bugs.

The disappearing editor was caused by Studio moving the method between the “Methods” and “Shared Methods” sections. During that refresh, the sidebar restored the highlighted method but accidentally cleared the active editor. Your code was still present, which is why duplicating the method shook the editor back into life. This is now fixed for the next release.

Your understanding of modules is also correct: a module is a static container, and all module-level members are implicitly shared. Writing Shared explicitly is accepted but redundant. Studio should not have displayed the Shared checkbox or treated explicitly marked module members differently - that has also been fixed.

As a rule of thumb:

Use a module for utility functions, constants, extension methods, and related nested types that do not require instances.
Use a class when you need instances, per-instance state, inheritance, or interface implementation.

Public, Protected, and Private remain meaningful for controlling access to module members.

https://feedback.objo.dev/bug/749

bgrommes

Garry OK that explanation helps a lot.

Those rules of thumb should be in the docs if you haven't already added them.

I guess in a sense this makes Modules inherently Sealed as well, since they lack inheritance. So a sealed static container. I like this; it gives Modules a role / use case rather than what I originally conceptualized them as, which is a backwards compatibility hack. It also discourages overuse of inheritance, and favoring composition over inheritance, etc. I would also expect module members to be slightly faster to access since they aren't implicitly virtual and the VM doesn't have to navigate a vtable or similar.

Garry

“Sealed static container” is a reasonable mental model, although a module isn’t technically a class and cannot participate in instantiation, inheritance, or interface implementation. I also wouldn’t choose modules for only for performance: Objo doesn’t use a conventional vtable here, and both instance and shared/module calls use cached VM dispatch. Modules are primarily a modelling and organisational choice.

I've tweaked the docs (in the next release) to be more clear.