@dan rathbun said:
Module syntax is NOT clutter. If you (speaking generally to all readers and especially newbies,) do not understand the importance of modules, then you do not understand how Ruby operates and how code is (and should be,) loaded.
Modules separate your code from other people's code, and prevent your code from "crapping" on the ObjectSpace (which is the same as "crapping" on everyone else's modules and classes, including Google's and Ruby's.) ANY script that defines methods, instance variables, class variables or constants in the ObjectSpace IS "crap." It does not matter if Google did it in their examples, it is still "crap."
NO CRAP Dan! 
Don't lecture me about the fundamentals of modules and namespaces. I know first hand the importance of modules. For without them, we would have so many name clashes that nobody could write code that did not blow chunks! The API would fall apart.
What i am referring to is the fact that Ruby makes you explicitly define module namespace! Wrapping up namespaces between syntax is a complete waste of time WHEN Ruby should create the module from each separate file -- like Python does! Python handles this so much more beautifully.
In Python, a programmer creates a module simply by writing code in a file. THE FILE WILL THEN BECOME THE MODULE. Do you see the beauty of such a system Dan? Even if you write toplevel code in the file (psst: thats a module Dan!) it does not matter. The code will be insulated from the global namespace by the module's namespace (psst: thats the file Dan!). And guess what else Dan...the FILE NAME then becomes the MODULE NAME. Woohoo! No need for more redundant syntax like Ruby forces on the programmer!
Ruby's modules are a monkey patch because Matz did not think far enough ahead when designing Ruby. Then he had to pull a "rabbit-out-of-his-hat" and came up with this module...code...end monkey business.
In Python, when we want to bring in all the names of a module we use the **from module import *** -- That means import everything. It's very much the same as what Ruby does with require HOWEVER, python gives you even more leverage with the from module import name1, name2, ..., nameN. With this statement you can choose to only bring in a few names and not the whole polluting shebang! But thats not all Dan, oh no, you can even import names and give them alias's right on the spot with the syntax from module import X as _X, y as WhyAskWhy, .... You see Dan Python is a far better choice for any scripting environment. Python was built with this very thing in mind from day one.
@dan rathbun said:
Not only should you be using A module around your script... you should be using nested modules. The outermost is your TOP_LEVEL namespace, Ex(using your SCF screenname):
module JesseJames
Any tool or plugin you create should be in a nested module (submodule,) of your TOP_LEVEL namespace. This allows individual tools or plugins to be removed from memory when they are no longer being used. TOP_LEVEL modules and classes can NOT be removed (by design.) This means the standard Ruby modules and classes, and Google's Sketchup, UI and Geom modules are safe. It also means a malicous coder cannot remove YOUR top level namespace. (It also means Google incorrectly put their modules at the toplevel, when they should have been within module Google. What happens in the future when Layout gets an API, and/or Picasa gets a Ruby API that integrates to Sketchup and Layout?)
Sadly all this nonsense would be unnecessary if we would adopt Python. Then we could concentrate on actually writing the meat and potatoes of our software instead of constantly worrying about name clashes from a scripting language with a piss poor design philosophy! Ruby is good for personal use and not much else.
@dan rathbun said:
Back to indenting... anticpating a chorus of whiney voices, thus:
Thanks for showing the class about how to maintain proper indention whist keeping the left margin minimal. This was a great and informative piece of text that should be posted some where were all can see and learn from.
@dan rathbun said:
Let's save Ruby vs Python for another topic thread, but for now, let me say in regard to your statement:
@jessejames said:
...it would be more elegant to use the file as the module (like Python does)..
that this CAN be done in Ruby using the wrap parameter of the load method. However it is simplistic and lacks control. The script is loaded into a temporary Anonymous namespace (module,) that is removed from memory when the script ends. So the important lesson here is the lack of controlling the namespace(s) under which the code runs, as well as controlling the persistance of the objects the code may create. Your just better off wrapping the code the namespace(s) ie, modules of your choice, to begin with.
Well i agree there is not much we can do. Our hands are tied. And not only with extending and patching this API, but also with the Ruby language proper as it too is boxing us in. We are basically surrounded on all sides by asininity and there seems to be no way out of this mess. Well, there is a way but trying to convince Ruby religious fanatics around here that greener pastures exists is almost a fruitless endeavor.
@dan rathbun said:
I have been tempted to write a Toilet plugin...<snip>...(And yes Google broke that rule in a few places, but it does not negate the rule. Example: The custom Sketchup Set class is defined at the top level, instead of as Sketchup::Set, and will clash with Ruby's standard Set class, if you load the latter.)
Ah yes. When the gods lead by bad example then the lemmings will follow them strait off the cliff. We need to do something about this mess Dan. You seem to be a smart, professional minded programmer. We need to get together, have a few beers, and discuss a battle plan for retaking this lost ship.
Currently SketchUp scripting is a captain-less ship left to the sport of every hacks whim. Someone needs to step in and lead by example. Rule with an iron fist, and kick some major butt around here. In times like these it takes drastic measures to bring about drastic changes. But in the end we will set sail on calmer seas. And graze on greener pastures.
