Modules - are they needed if ...

chrisglasier

... you could load the script required for a task in hand so that it overwrote anything in memory that conflicted with it?

I have been experimenting with this with Javascript and it seems to work provided the loading and call is a two step process to allow the script to load.

For example I have a set of keys (one of which might be color), to which I have attached a function (say setColor) and the function simply has three color options. Selecting the key loads the script file containing the function, selecting a color option puts it to work. I feel I'm being far too simplistic about this but I cannot see yet what is wrong.

I am looking for enlightenment!

Dan Rathbun

Are you asking if "Ruby modules are needed if ..."

.. if so, the answer is simple, and always YES...

YES you should always have YOUR code protected within YOUR toplevel namespace to avoid object identifier conflicts.

It can be anyname you wish: module Glasier sounds good to me.

Divide up your namespace into sub sections.. for example you would likely want each of your specific plugins to enjoy it's own sub-namespace, ie it has a sub module of it's own.

Let's say your project is ColorWidget:

module Glasier

  module ColorWidget

    def setColor()
    end # def

  end # ColorWidget

end # Glasier

The terms you are using are really not Ruby terms, so I think when you say "I have a set of keys (one of which might be color),".. I think you mean to say instance attributes (aka @variables)...

When you say "to which I have attached a function (say setColor) and the function simply has three color options" .. I think you are saying that the @var will be a custom class instance, with a instance method named setColor()

So:

module Glasier

  module ColorWidget

    attr_reader(;color)

    class MyColor
      def setColor(opt)
        # if statement for 3 options
      end # def
    end # class

    def main()
      @color = MyColor.new()
      #
      # more code to run the plugin
      #
    end # ColorWidget.main()
    module_function(;main)

  end # ColorWidget

end # Glasier

Notice how the custom class MyColor is local to the ColorWidget plugin submodule.
If you would use that class in more than one of your plugins, you would instead define it one level up it would be Glasier::MyColor instead of Glasier::ColorWidget::MyColor

Now.. dynamically redefining objects: Ruby was designed to do this.

Let's say at some point you want to change the way that the setColor() instance method works, in class Glasier::ColorWidget::MyColor. You create a little script to modify the existing class, by redefining ONLY those things you wish to redefine:

class Glasier;;ColorWidget;;MyColor

  def setColor(opt)
    # new code - different from
    # the default startup code
  end # def

end # class

Notice how once the outer namespaces are defined, you can use shorthand qualification.

chrisglasier

Thanks Dan. Actually I have used modules as you describe in my rather puny attempts at making Rubies and I appreciate the refresher. But lately I have been considering JavaScript device plug-ins (could be for a web dialog) as I described in the first post. Conflicts (I think) are controlled by loading or reloading a required device so that its functions overwrite any previous with the same name.

It seems to me that provided the core functions were prefixed with reserved characters (qxq) then external device makers did not need to worry about any other naming conventions and I need not worry about laying out no-fly zones and policing them (malicious code and spam is another topic). So if this is OK with JavaScript (and that is one question) I wondered whether it would be similar with Ruby (which you have answered). I do understand that in some other languages two functions/methods of the same name will not overwrite if the number of parameters are different.

Thanks

thomthom

Javascript namespacing:
http://www.dustindiaz.com/namespace-your-javascript/
http://www.crockford.com/javascript/private.html

chrisglasier

@thomthom said:

Javascript namespacing:
http://www.dustindiaz.com/namespace-your-javascript/
http://www.crockford.com/javascript/private.html

Thanks for that TT - all good stuff which I have implemented in part - still really trying to get to grips with it though.

But my current concern relates to this Diaz comment:

@unknownuser said:

... avoid conflicts with external application code, playing nice with the "other JavaScript kids," ...

I don't think relying on playing nice is realistic in a global environment but making sure same named objects and functions overwrite existing by loading or reloading immediately prior to use may be. I'm just not sure if there are other implications.

Thanks