Plugin recommended practices

sepultribe

# encoding; UTF-8
#{ =========================================================
#  Documentation block ...
#} =========================================================
 
require 'sketchup.rb'
module Author
  module ThisPlugin

    # CONSTANTS defined here
 
    # Module @@variables defined here

    # Classes unique to ThisPlugin defined here
 
    class << self
 
      def init()
        # define instance @variables here
      end

      # def plugin methods here
 
    end # proxy class
 
    # Run Once at startup block here;
    this_file = Module;;nesting[0].name <<';'<< File.basename(__FILE__)
    unless file_loaded?( this_file )
 
      init() # call the init method if needed
 
      # define commands, menus and menu items here
 
      file_loaded( this_file )
    end
 
  end # plugin module
end # toplevel module

Are sketchup.rb and extensions.rb still required for SU plugins? What does init() help with? And what does a singleton class give us since everything is inside a module?

Dan Rathbun

That is the sample file I posted over at the sketchup.com forums, I think.

"sketchup.rb"
The require "sketchup.rb" is only needed if you call any of the methods defined in that file. Since SketchUp 2014 the "Tools/sketchup.rb" file is loaded automatically before any plugins ever get processed. So the actual require call is frivolous, but some documentation generators use it to list dependant files. (So it is still good practice.)
In this case, the global methods used file_loaded?() and file_loaded() are defined in "sketchup.rb", so I added the require "sketchup.rb" call.
But you can create your own editions of similar methods within your own author module, or plugin module, or a custom mixin module (within your author module,) that you can include in any of your plugin sub-modules.
In other words, I encourage becoming independent of "sketchup.rb", as it's fixes are long overdue from being added to the API, in the correct modules or classes.

"extensions.rb"
Yes "extensions.rb" is still needed. But the file above is a simple template of a "core" plugin file, that resides in a plugin sub-folder (or the "Plugins" folder,) which gets loaded by an extension registration script (which resides in the "Plugins" folder.)
For an example of the registration script, see the API's SketchupExtension class:
http://www.sketchup.com/intl/en/developer/docs/ourdoc/sketchupextension

Anonymous Singleton Proxy Class Instance
The proxy object, in this case, is the module itself. The methods defined within are accessible outside the block without qualification, as if you qualified the calls with self.methodname(). Any constants or module variables from outside are accessible inside the block.
init method
But because of the unique syntax, they are not instantiated like normal class instance objects, and so have no new() constructor method, which calls the newly created instance's initialize() method, where instance variables are usually initiated. Also because they are a class block, raw statements do not get evaluated like they do outside at the module definition level. (Why, I do not know.)
So somewhere outside the block, a call must be explicitly made to some setup-like method within the block, to initialize any instance variables that need to start with some value other than nil. (Uninitialized instance variables that are referenced will return nil.)
This setup method can be any name you choose,... I chose to use the name init() in the example template.
If you have no instance variables, you do not need such a method to init them.

If you do not like using a proxy class, you can explicitly define all your methods as module methods, ie:
def self.methodname( arguments )
but then you will have to qualify all calls using self.methodname ...

Since most newb's try to define all their methods like instance methods, and call them without qualification, I figured it was best to just have them put the methods in a proxy class instance block.

I prefer it myself. But to each their own.

sepultribe

very much appreciated, thanks for the detailed response