@thomthom said:

GitHub - thomthom/SKUI: Ruby wrapper of classes that maps to GUI controls in SketchUp's UI::WebDialogs

Ruby wrapper of classes that maps to GUI controls in SketchUp's UI::WebDialogs - thomthom/SKUI

GitHub (github.com)

Could you add version to README.md? Pretty please with a cookie?

I have with the aid of snippets and Alexander C. Schreyer's Ruby Code Editor stumbled my way to a example that does what I wish. Its of the form:

#
# bbtools.rb script to add tools for bounding box manipulation
#

module HSM
  module BBTools
    class BBTool

.
.
.
vital essence
.
.
.
    end # class BBTool
  end # module BBTools
end # module HSM

and while in the editor I invoke it with:

tool = HSM;;BBTools;;BBTool.new()
tool.runTool()

At this point I'd like to make it a 'real' extension. By that I mean add it to one of the pull down menus in SU. I believe I need to do this in a separate file where I essentially tell SU about my tool and where I will place it.

there is also the matter of:

Extension Wrappers; All extensions in the Extension Warehouse must be wrapped
with a SketchupExtension class so that the user can enable and disable the
extension from the Preferences dialog and/or the Extension Warehouse UI.

At this point I admit to being clueless about how to accomplish this last step. My goal is to at some point publish and I believe that adds a layer of complexity as well.

Advice? Suggestions. Brickbats? Catcalls? Bring it on---Please !!

@slbaumgartner said:

Perhaps you really mean whether to use classes or not, as in Ruby everything is an object! This question is likely to get somewhat religious answers from OO fanatics!

Ah! You've detected my plan A lively discussion would be a good thing!

@slbaumgartner said:

You should use at least modules to isolate namespaces. In Ruby the differences between modules and classes are more subtle than in many other OO languages, but it really comes down to whether the things you are coding need to have individual memory (state) hence be instances of a class, or just shared configuration in which case you could use either.

Good explanation, without frou-frou. I'm familiar with C++ (very), Smalltalk (less very) and most of the script languages currently around---I'm a bit of a language slut, seldom seen one I didn't find interesting enough to learn. Because of this I am aware of OO both integral as well as bolt on, say Python versus Perl. My preference is bolt on but that's not a statement of value just something based on experience and my programming origins (IBM-BAL was my first).

Your rationale for using an object/s agrees with my preferences particularly with short succinct code like my extension, but the discussion is young yet!

@slbaumgartner said:

The first level keeps your namespace clear of anybody elses.
The second level keeps this extension's namespace clear of your other extensions (it happens! I just had a collision between two of my extensions when I forgot about a name I had used already)
I think a third level would be needed only in a complex suite of extensions such as Fredo6 or TomTom develop - though of course any class you define inside the second level creates a third namespace.

Useful explanation with war story The last bit reminded me where I'd seen the third level, so quite helpful!

Given a simple extension should it be 'objectified'? By definition, it is already an object, so is there a preference to go further? Having started before C++ but after Simula, my habit is to only sparingly use objects and then usually to make the code more straight forward. If the language is missing something and I can best model it as an object then that's what I will do, otherwise I tend to see it as overhead. Please correct or enlighten me as needed.

I've a extension naming question regarding module nesting. Which is it, 1, or 2 levels? I.E.:

Module HSMNameOfModule

or,

Module HSM #Author namespace
  Module NameOfModule #extension namespace

I have foggy memories of seeing 3 deep nesting but have forgotten the details.