Any SketchUp plugin will define names
in at least a few namespaces
In order to "play nicely" with other plugins (and SketchUp itself),
it should keep this presence as unobtrusive as possible,
consistent with its functional requirements.
This page examines some naming issues
that affect the Extension Framework
and the plugins it manages.
Directories and Files
SketchUp normally runs on either Mac OS X
Both of these operating systems
use hierarchical file systems
SketchUp defines (and enforces, in come cases) OS-dependent conventions
regarding the location and naming of directories and files.
- The extension's "loader" script must reside in a location
.../Plugins) that is appropriate for the OS.
- The script must have a unique name with an "rb" extension.
- Plugins (eg, loader scripts) should be the only Ruby (
files that are located in the plugins directory.
- Normally, any associated files for a plugin should reside
near the plugin, in a similarly-named sub-directory (eg,
EF follows these practices, with minor additions and exceptions:
EF generates the directory and file names (in the Plugins directory)
that are used by the extension sets it manages.
For example, consider the
Extension Set (ES):
- The loader script is named
com_cfcl_public_dev.rb for development mode).
- The associated sub-directory is named
EF's names in the Plugins directory (and its single global)
use the popular Reverse-DNS
For example, because CFCL owns the domain name
it has the moral authority to derive other names from it.
This approach precludes most name collisions, indicates the origins of entities,
and "clusters" related content in (at least) the Plugins directory.
EF also defines a few "private" file trees (eg, in
SketchApps_dev - development extensions, etc.
SketchApps_tmp - temporary (session) files.
SketchApps_use - usage (eg, config, log) files.
Each loader script creates a
using the ExtensionsManager
foo_loader = SketchupExtension.new(foo_name, foo_path)
- The extension's name will be used in a SketchUp dialog,
so it should be memorable, short, and unique.
- The extension's path will be used to load the extension,
so it should (with very few exceptions) be unique.
Any Ruby constants (eg,
) that are defined outside
of a module (or class) are global by default.
So, Best Practice is to wrap each extension in a Ruby module.
This provides a private namespace for its internal
(eg, class, method, variable) names.
Unfortunately, if the module itself
has a name (eg,
a conflict could still occur.
So, EF uses an anonymous module for this purpose, eg:
foo_module = Module.new do ...
EF uses no global constants of its own
(though libraries such as
are still an issue).
To avoid conflict among its own managed plugins,
EF also wraps each one in an anonymous module.
Any global that an extension (or other plugin) defines
will be visible throughout Ruby's run-time environment.
So, Best Practice is to:
- define as few globals as possible
- use long, distinctive names
Only a single global variable (
) is used for EF data.
This wiki page is maintained by Rich Morin
an independent consultant specializing in software design, development, and documentation.
Please feel free to email
comments, inquiries, suggestions, etc!