[Example] box.rb version 2.0.0

Dan Rathbun

[Example Script]

box.rb version 2.0.0

Revised Google Example script, replace original in Plugins/Examples folder.

Version: 2.0.0 - By Dan Rathbun, 17 APR 2010

Wrapped in namespace Examples::SU::Box

method create_box was clashing with a method of same name in file:

Tools/make_pano_pm.rb

EDIT: Just a note I saved the box.rb file with UNIX end of line chars, for cross platform use.

Unzip to Plugins/Examples folder

frankc3250

Thank you so much! This has been driving me nuts.

Regards,
Frank

Dan Rathbun

@frankc3250 said:

Thank you so much! This has been driving me nuts.

Your quite welcome, Frank. Glad I could help.

So does this mean I can turn my SketchScout pin right-side up for today?

For those interested in what prompted this revision, see the following thread over at GoogleGroups:
http://groups.google.com/group/sketchupruby/browse_frm/thread/96975c731eabf8b1#

Edson

would you care to explain what is the difference between your version and the one that packs with sketchup?

Edson

dan,

thanks for the clear explanation. not being a ruby coder myself sometimes even simple issues are difficult to understand.

Jim

@dan rathbun said:

In addtion I made the create_box method a module function (see Ruby Pick-Axe book: module_function)

Dan, I have seen module_function used, and have read the documentation.

@unknownuser said:

module_function: [1] Creates module functions for the named methods. [2] These functions may be called with the module as a receiver, and also become available as instance methods to classes that mix in the module. [3] Module functions are copies of the original, and so may be changed independently. [4] The instance-method versions are made private. [5] If used with no arguments, subsequently defined methods become module functions.

[1, 2] From what I gather, it allows the method to be called within the namespace without using self. Is this merely a convenience, or are there other implications?

[2] It is normal for module functions to be available as instance methods - that's how mixin work; so that behavior seems unaffected.

[3] I'm not sure I understand what is meant by the functions being copies, and what that implies. If you mix-in a module, its functions become instance methods in the class. You can still redefine the mixed in methods in the class, so I am unsure what making them copies accomplishes.

[5] Every method following a module_function declaration becomes a module function.

Dan Rathbun

@jim said:

[5] Every method following a module_function declaration becomes a module function.

Um.. are you saying that the newset doc has changed the way module_function works?
Or.. that it does NOT work according to the docs? [ie a Ruby Core bug.]

The old 'Pick-Axe' book for ver 1.6.x says if an arg list is given it applies to the methods identified by symbol, but without an arg list then it applies to following methods. (Similar in how public, private and protected work.)

EDIT: The latest docs have no change from the old '1.6.x' docs. See:
http://www.ruby-doc.org/core/classes/Module.html#M001642

Dan Rathbun

@jim said:

[1, 2] From what I gather, it allows the method to be called within the namespace without using self. Is this merely a convenience, or are there other implications?

I don't think this is an accurate analysis. module_function really allows the opposite, where normally a private instance method can be called from within the namespace without .self, AND you wish to ALSO allow calling it from OUTSIDE the namespace with namespace qualification. When you use module_function, it makes a singleton copy of the instance method, so there are actually two methods of the same name, create_box (instance) and self.create_box (singleton.)

I can then call either of them from within the namespace by using or not using the .self qualifier.
And can call the singleton (ie module function,) from OUTSIDE the namespace by using namespace qualification.

Although box.rb is not really written in a way that makes it a good mix-in module (ie the configuration dialog part is in the same method as the geometry creation,) I still did it in case someone wished to "play" with it as a mix-in module.

I could have just used the .self qualifier and went with a singleton method only.

Anyhow, the Pick-Axe has a simple example, but is unaccessible in the online version. You'll have to use the CHM version, and look at The Ruby Language > Module Definitions > Module Functions
It shows how you can access a certain method (IF it's a module function,) in another module without having to mix-in (ie, "include") the ENTIRE module. If the author of the Mix-In module did not do it, YOU can use module_eval to cause a method in another module to have a module function copy, like:
MixIn.module_eval('module_function(:InstanceMethodName)')

Dan Rathbun

@edson said:

would you care to explain what is the difference between your version and the one that packs with sketchup?

I did in the first post of this thread. I wrapped the original code like thus:

module Examples
  module SU
    module Box
      # the original create_box method
    end # Box
  end # SU
end # Examples

In addtion I made the create_box() method a module function (see Ruby Pick-Axe book: module_function)

I also made a small correction, by moving the last line up inside the preceeding if block.

I marked all lines that were added or moved.

Wrapping the code, in it's own namespace prevents it from being corrupted by scripts that load afterwards, that have methods (or other objects,) with the same name.

What was happening was, that after box.rb loaded, then later make_pano_pm.rb would load, and it ALSO had a method named " create_box". Since neither script (originally) was wrapped in a module they were actually defining methods within the SAME namespace (which is class Object.) Whenever Ruby reads a method definition of a method that is already defined, it deletes the old method, and replaces it with the new one.
So.. make_pano_pm.rb was redefining the create_box() method that both scripts were trying to use,... BUT the latter one was not written to work with both scripts, and users trying to use box.rb would never see the box dimensions input dialog appear.

If you did not have make_pano_pm.rb in your Tools folder (dir,) then box.rb would work normally, and you would not notice anything amiss.

I did NOT change or improve box.rb to be a better plugin, because it's not a plugin. It's really a simple code snippet, to be used as an example and a base, from which ruby-newbie's are to play with and improve themselves, thereby learning by doing.