Understanding module wrapping?

tomot

I recognize the preferred way to write rubies is to wrap your class in a module namesake. The following code works without module wrapping.
If I wrap my class with module TOMOT and end # module TOMOT
What do I have to change in this code to make this code run with the new module wrapping?

#-----------------------------------------------------------------------------
def righttriangle
    Sketchup.active_model.select_tool RightTriangle.new
end

if( not file_loaded?("RightTriangle.rb") )
    add_separator_to_menu("Plugins")
    UI.menu("Plugins").add_item("Right Triangle") { Sketchup.active_model.select_tool RightTriangle.new }
end
#-----------------------------------------------------------------------------
file_loaded("RightTriangle.rb")

Dan Rathbun

Something like this:


# ----------------------------------------------------------------------------

module Tomot

  module RightTriangle

    class RightTriangleTool
      #
      # Tool definition
      #
    end
    
    ### Module Vars (declare outside the "self" proxy class.)
    #
    @@tool = nil  # leave nil until the tool instance is needed.

    
    class << self  ### proxy class (def all methods inside this.)
    
      #  use()
      #
      #  Use the plugin's tool.
      #  (Creates the instance when it's first called.)
      #
      def use()
      
        unless @@tool
          @@tool = RightTriangleTool.new()
        end
        
        Sketchup.active_model.select_tool( @@tool )

      end # use()


    end # class << self


    unless file_loaded?(File.basename(__FILE__))
    
      add_separator_to_menu("Plugins")

      UI.menu("Plugins").add_item("Right Triangle") { use() }

      file_loaded(File.basename(__FILE__))

    end

    # ----------------------------------------------------------------------------
  
  end # RightTriangle
  
end # Tomot

kyyu

tomot, my layman's answer is you need to prefix the module method with the module name space. Even though; in your example, you don't use the method you defined. Instead of "def righttriangle", it should be "def TOMOT.righttriangle" or "def self.righttriangle".

Dan Rathbun

He needs to do it the way I show.

.. and use Tomot as a module name, not TOMOT.
We use all caps for constant identifiers, by convention. (Sometimes an acronym is used as a module name, ie UI, or XML, but we all know why, and these are special cases.)

Chris Fullmer

Hey Dan, I'm checking out your example and it is looking good.

Just to verify, it looks like you are making the RightTriangle class the tool class - all tool functionality should be defined in there like all the onMouse events, and the draw method, etc.

And then you have everything else put inside the "class << self" proxy class. So that is where the bulk of the code would go for the rest of what happens while the tool is active.

Is that approximately right?

Chris

Dan Rathbun

@chris fullmer said:

Just to verify, it looks like you are making the RightTriangle class the tool class - all tool functionality should be defined in there like all the onMouse events, and the draw method, etc.

Not exactly... the RightTriangle module is the specific plugin module inside his "Author" namespace (in this case, the Tomot module.)
Since only this specific plugin, needs access to this plugin's custom tool, (in this case the RightTriangleTool class,) it is defined within this specific plugin module ( RightTriangle.)

@chris fullmer said:

And then you have everything else put inside the "class << self" proxy class. So that is where the bulk of the code would go for the rest of what happens while the tool is active. ... Is that approximately right?

Well... a Tool class object, is an event driven object. "The rest of what happens" are the actions of the user, which are interpreted by the Sketchup engine, which makes callbacks into the Tool instance (ie, onmousemove, etc.) The "handle" to the tool's instance is created by the use() method (if it does not exist,) and is referenced for later access via the @@tool var.

You can define other methods within the proxy class block, to do other plugin management things. For example, many plugins have multiple tools, so there may be several tool definitions within the plugin namespace, and multiple "use" methods, ie: use_widget(), use_gadget(), use_doodad(), use_thangy(), etc., within the proxy class block.

It's also possible for the tool constructor new() call, to pass a self reference "down" to the tool's initialize() method, to make calling methods up in the plugin namespace easier.

Now if you wanted to allow other people to select your tool from other scripts, you can define a singleton method outside the proxy class block, but within the plugin namespace, like:

self.use_tool()
  use_tool()
end

Then they would call: Tomot::RightTriangle.use_tool()

Of course the naming of these public access methods may be more specific, if there are more than one tool in the plugin.

kyyu

Dan, I now see I didn't understand alot of it until, you just explained more. When you use @@tool to save the tool instance, do you think there are efficiency gains?

thomthom

@kyyu said:

Dan, I now see I didn't understand alot of it until, you just explained more. When you use @@tool to save the tool instance, do you think there are efficiency gains?

For one it would allow you to store the state of the tool...

kyyu

@thomthom said:

@kyyu said:

Dan, I now see I didn't understand alot of it until, you just explained more. When you use @@tool to save the tool instance, do you think there are efficiency gains?

For one it would allow you to store the state of the tool...

Thomas, could you give a real simple example of this. I know you can save @@variables, that will be remembered within a SU session. But confused by the tool state, being remembered with the instance.

Dan Rathbun

Programming a Tool class is another topic. It's best to read the examples supplied by Google, in the "Plugins/Examples/linetool.rb" the instance var @state is used to store what 'step' the tool is at.