@brewsky said:
And after thinking on this, maybe TT's way of just making a module as a base-object for the plugin is a better approach than my BimTools-class. Because is't only used once, the module-approach seems more fitting...
Oh hell yes.
If you need only one copy of a code object, then generally it should be a module.
If you need multiple copies of a code object (usually because the code must adapt to many other instance objects,) then you make it a class, and instantiate instances that are syncronized to a particular instance object.
Often coders try to avoid using a module, because they think it's a static kind of object, and they believe it is harder to use than a class instance.
What they miss is, that a module definition, is really an instance of class Module. So for example, your nested module Brewsky::BimTools::Manager is actually an instance object, and the preceeding identifier is the reference to the instance.
If you remember this... then it can be easier to understand how using an anonymous singleton proxy class instance inside your Module class instance, makes sense.
Imagine the Module class is "the hen".
It lays an egg, which is your nested Manager module instance, that could be created thus:
` Brewsky::BimTools::Manager = Module.new {
plugin managerial code here
}But the Ruby interpreter calls the new()` constructor for you on the C-side of things. (Ie, the defintion block syntax for scripts, was invented for human happiness and readability; Ruby itself does not really need it.)
But having methods in modules communicate (call each other,) works a bit different than in a class definition. Instance method definitions in a module, are meant for Library Mixin modules. (Read up on the include and extend methods.) They become different kinds of methods, depending on whether they are mixed into a class or module, and whether include and extend is used to do the mixing.)
So at first blush, the coder thinks they must define all methods in a module as module functions that must be called with self.method_name(), ... they find this cumbersome, and they switch back to using a class defintion, and using only one instance of it. (A sort of psuedo-singleton class.)
BUT.. the egg can have a membrane inside it's shell. This membrane analogy is the anonymous singleton proxy class instance created with the following syntax:
module Brewsky
module BimTools
end
end
module Brewsky;;BimTools;;Manager
# module variables and constants declared here
MGR_VERSION ||= '1.2.3'
@@bimmenu ||= nil
class << self # self evaluates to the module instance
# Everything in here acts like a class
# instance BECAUSE IT ACTUALLY IS !
# In here we can access the module @@vars directly.
# In here we define instance methods, not module methods.
# But if they are public, they can be called like module
# functions, from anywhere outside the module.
private
def get_version()
MGR_VERSION
end
# In here we can call any other method in here,
# without module qualification.
public
def version()
get_version()
end
end # proxy class
# Out here we can call any of the methods inside
# the proxy class directly, without qualification.
unless @@bimmenu
@@bimmenu = UI.menu('Plugins').add_submenu('BIMTools')
@@bimmenu.add_item('Version') { UI.messagebox("BIMTools ver #{version()}") }
end
end # module Brewsky;;BimTools;;Manager
# 99.9% of the time, there is no good reason to
# have any executing code outside your namespace.
EDIT(2012-12-16): changed post title to "Why use a module instead of a class ?"
