As a software project grows, your biggest challenge is no longer just writing code—it's organizing it. Unmanaged complexity leads to naming conflicts, tangled dependencies, and code that's impossible to maintain. ObjectSense (OSE) tackles this head-on with a clear and robust system of Packages and Modules.
This guide will walk you through OSE's approach to code organization, from basic file structure to creating reusable and distributable frameworks.
Packages: The Building Blocks of Your Codebase
In OSE, the most fundamental unit of organization is the Package. A package directly maps your directory structure to a logical namespace, providing a simple yet powerful way to group related code and prevent naming collisions.
Defining a package is quite straightforward: just use the Package keyword at the top of your file.
OSE enforces a strict rule: each source file can only declare one package, and the package name must match its directory path. This might seem rigid, but it creates incredible predictability. You can always find a piece of code just by looking at its package name.
Bringing Code Together: The Import Statement
The true power of packages is realized when you reuse code. The Import statement lets you bring resources from other packages into your current scope. OSE provides several specific import types to give you precise control:
● Import variable: Imports a class definition. You can then create instances of it using CreateInstance("ClassName").
● Import static: Directly imports static methods, allowing you to call them as if they were local (e.g., s:Check()). This is great for utility functions.
● Import const: Imports constants defined with Let!.
● Import enum, Import note, Import micro, Import flaw: Specialized imports for enums, annotations, macros, and exceptions, respectively.
Modules: Creating Reusable and Distributable Units
If a package is a single tool, a Module is the complete, shippable toolbox. A module is the smallest, self-contained, and reusable unit of functionality in OSE. It consists of one or more packages, other resources (like assets or config files), and a crucial manifest file named Sense.ose.
The Module Manifest: A Deep Dive into Sense.ose
Every module is defined by its Sense.ose file. This file acts as the module's identity card, containing its metadata, dependencies, and rules of engagement. Let's break down its key fields:
● Core Properties: description, version, and main are the basics. They define what the module is, its current version, and its primary entry point for execution.
● Dependency Management: The require field lists all other modules or packages that your module depends on. This ensures that when your module is loaded, all its dependencies are correctly resolved and loaded first.
● Defining Your Public API: The export field is critical for creating robust libraries. It allows you to explicitly declare which packages, classes, or functions are accessible from outside the module.
● Advanced Customization: The parser and command fields offer powerful extension points, allowing you to define custom configuration parsers or add new rose commands for your module.
Anatomy of a Module: A Practical Example
Here's how these concepts come together in a typical module's file structure:
app-foobar-hello/
├── Sense.ose
└── src/
└── foobar/
└── hello/
└── render/
├── AddressSenseParser.ose
├── HelloCommand.ose
└── Index.ose
In this structure:
● Sense.ose defines the entire module's properties, dependencies, and public API.
● The src directory contains the package structure (e.g., foobar.hello.render).
● Index.ose contains the main application logic.
● AddressSenseParser.ose and HelloCommand.ose are advanced extensions defined in the manifest file.
By providing this structured system, OSE gives you the tools to move beyond simple scripts and build large, complex, and highly maintainable applications with confidence.
In our next stop, we'll dive deep into Object-Oriented Programming in OSE, exploring the world of classes, inheritance, and polymorphism.
Top comments (0)