Nested Types

bgrommes

Per the docs (so far as I can tell, only in the documentation of the solution / project file format), Objo supports nested types, specifically, nested classes and modules. But I don't find any docs on how to create, say, a nested class in Objo Studio.

I can right-click on the class and under "Add to classname >" I can add, say, an enumeration which becomes a class member like a property or method (which begs the question, can I create a shared enumeration that would be available anywhere? If so, I don't see how.) BUT I can't add a class to the class, and I don't see any other way to do this nesting whereof the docs speak.

I think this is a gap in the documentation; I'd like to see a discussion of what Objo does and doesn't support in terms of nesting, any limitations, how it works in the Studio UI rather than in code, etc. Preferably something that will come up high in the search result for "Nested".

Garry

This is a good catch. The terminology and Studio workflow aren’t explained clearly enough.

In Objo, a “nested class” currently means a class contained inside a module. Classes cannot contain other classes, interfaces, or modules, although they can contain enumerations.

To create a nested class in Studio, first create or select a module in the Solution Navigator. Right-click the module and choose Add Class. The new class will appear beneath the module and can be referenced using a qualified name such as Utilities.JsonHelpers. The same process can be used to add nested interfaces and modules.

For an enumeration that is accessible elsewhere, you can add it to a module:

Module GameTypes
    Enum Direction
        North
        South
        East
        West
    End Enum
End Module

It can then be used as GameTypes.Direction. If several projects need it, put the module in Shared Code.

The language documentation does discuss modules containing types, but it doesn’t adequately explain the Studio workflow, the supported combinations, or the difference between an enum embedded in a class and a nested source item beneath a module. The fact that “Nested” led you mainly to the solution-file-format documentation confirms the discoverability problem.

I’ll improve the documentation so that searching for “nested types” leads to a clear explanation with Studio instructions and the relevant limitations. I also agree that Studio should make top-level/shared enumerations easier to create directly so I'll look into that.

Garry

Quick follow-up: I’ve now implemented the Studio improvement mentioned above.

In the next Objo Studio release, you’ll be able to create a top-level enumeration directly. Select a project, project folder, Shared Code, or a Shared Code folder, then choose Add Enumeration. It is also available from Insert > Enumeration, the workspace Add menu, and with Cmd+Option+E on macOS or Ctrl+Alt+E on Windows/Linux.

Where the enumeration is created determines its availability:

An enumeration in a project is available throughout that project.
An enumeration in Shared Code is available to every project in the solution.

No Shared modifier is needed. For example, a top-level Direction enumeration can be referenced directly as Direction.North.

The existing nested-enumeration workflow remains unchanged: right-click a class or module and choose Add to ItemName > Enumeration when the enumeration should belong to that type.

I’ve also expanded the documentation (will be live when the next release drops):

Thanks again for highlighting both the documentation gap and the missing direct Studio workflow.

bgrommes

Garry Thanks, Garry.

I don't have super strong feelings about classes nested in classes (or functions nested inside functions) but have occasionally used both to good effect. For example I have certain business name scrubbing methods that take an EntityModel class as an argument and that in turn contains a primary name, a care of name, and zero or more DBAs. The idea is to give the same treatment to all names that are present with one call. Within that method, call it Blah(), there's a nested method called BlahInternal() that takes a single name. The outer function passes one name at a time from the passed EntityModel.

There's nothing that says this HAS to be done this way, you can just as easily have a private BlahInternal() method to call from the public Blah() method. It's just that this method has no applicability outside the internal use of Blah() and nesting it makes that intent clear. If the situation changed later, moving it outisde of Blah() is a non-breaking change.

So it's another one of those things that's nice to have as an option, but not exactly an absolute requirement.

Nested classes have an arguably better use case. Sometimes you need a specialized DTO or struct that the class only would ever use internally. But even these can be separate, private definitions.