[talk] Using Ruby Modules

jessejames

@dan rathbun said:

[talk] Using Ruby Modules

Please use this thread to discuss issues relating to Using Ruby Modules,
and not the informational thread: [info] Using Ruby Modules

@unknownuser said:

Note i have moved my response from the aforementioned thread to this thread at the request of Dan. And here it is in all its glory...

@dan rathbun said:

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.

And i would add to that...

@unknownuser said:

You should not write any scripts (note i did NOT say CODE) until you do understand Ruby modules!

Thanks for posting this info Dan. Not only are almost zero newbies following this advice! Almost none of the more professional guys are following it either! And sadly if you don't instill proper values in a programmer from day one you can NEVER instill them later on! Old dogs cannot learn new tricks. And unlearning a bad habit is SO much harder than learning a good one to start with. Programmers are by nature a lazy bunch, so we need to trick them into good habits from day one.

Anyway, although i'm probably just wasting my breath... all this module munbo jumbo of "jumping-through-bad-ruby-module-design-hoops" would not be necessary with Python's elegant module system. But i won't replay that broken record here again.

Anyway the real reason i replied is because i would for you and I to create a nice WORKING example of the very nested module system you are referring to. And what better example to use than all the script in the default SketchUp examples folder...

animation.rb
attributes.rb
box.rb
contextmenu.rb
linetool.rb
selection.rb

The bad thing about a system like this is the fact that if people find it too confusing to implement they will just choose to be lazy instead -- and the last thing we need to do is help spread MORE laziness around this group! I always say a working example is the key to understanding systems like this.

What do you think Dan? Heck, maybe if we're lucky sudev will actually release it in the next major version -- however don't hold your breath!

EDIT: Added some post thoughts
I just wanted to add a small footnote for all the endless drones of whiners who say:

@unknownuser said:

Wah! Wah! Rules are not fair and they make my brain hurt! Wah!

Listen up you little baby. SketchUp scripting is a community effort. Whether you release scripts for fee, or for fee, you have a responsibility to the community to maintain a certain degree of uniformity and style. You do not have the right to crap on every one else by releasing buggy, sloppy, or namespace "slut-ing" code that infects MY namespace with it's bugs.

You can think of scripting in a community the same as driving in a community. Driving is not a right it's a privilege. If you go out and run stop signs and red lights just because you're too lazy to press the brake pedal (Wah!) then you need your license revoked and your little bottom smacked! (yea then you'll have something to "Wah!" about!)

Now, if you are writing scripts only for you then by all means be as sloppy as you wish. But don't give me this cry baby Wah crap about how rules will limit your freedom to be lazy because i don't care.

You do not have a right to be lazy when your laziness causes harm to others. Have you ever heard of involuntary manslaughter?, same thing! When your actions (whether by lack of action or by an accidental action (read as stupid action!)) cause the death of another human being you have committed a crime. Likewise when you choose to write scripts in a lazy, sloppy, and namespace "slut-ing" style you have err'ed against a community. If you enter my namespace you have trespassed on private property.

Freedom is great, unbridled freedom is the root of all evil!

Dan Rathbun

@unknownuser said:

Note i have moved my response from the aforementioned thread here at the request of Dan. And here it is in all its glory...

Wow.. glorious! Thanks JJ for moving this over here.

@unknownuser said:

You should not write any scripts (note i did NOT say CODE) until you do understand Ruby modules!

It is so amazing!

The newbies say they've read such and such a book, and still don't understand modules. The old-hands have read several books and coded for years and didn't really understand modules.

The fault lies with the tutorials and authors of the books. I cannot slap people around, because it's not their fault. (Slap the authors!)

One of the things I hate most, about the Ruby books is, they decided not the scare away newbies, by pretending Ruby has variables. They even (badly IMHO,) call object references variables. Some idiot thought that it would twist people's brains in knots if they revealed this fact too early. So (it seems,) they conspired to save the surprise until the second semester course, or the advanced book.

Well.. guess what? People are impatient. They don't read the advanced book, or take the second semester course. They jump in and start hacking, and run smack into "coding walls" because they think they are assigning values to variables, instead references that point at objects.

@unknownuser said:

Thanks for posting this info Dan. Not only are almost zero newbies following this advice! Almost none of the more professional guys are following it either! And sadly if you don't instill proper values in a programmer from day one you can NEVER instill them later on! ...

[Devil's Advocate] Until recently there was not very much in print to teach Ruby to newbies. The old hands had to "wing-it", and what was available, was very simple. The oldest tutorials followed the "Hello World!" model (which should be outlawed.)

Hey look at rubylang.org telling people they can teach them "Ruby in 10 minutes" (that's the name of the tutorial.)

@unknownuser said:

Anyway, although I'm probably just wasting my breath... all this module munbo jumbo of "jumping-through-bad-ruby-module-design-hoops" would not be necessary with Python's elegant module system. But i won't replay that broken record here again.

It's OK if we disagree on this?

I love Ruby's module syntax. I'd rather have it stated at the top of the code, than need to look at the editor's caption bar.

The filename namespace feature of Python I don't care for, and would not want it to be added to Ruby, UNLESS it was applied ONLY in the event a script was not explicitly module wrapped within the code. (But I can do this with my planned ObjectSpace Police plugin.. it's on my list, believe me!)

I'm wary about automatic filename namespaces as 80% of everyone I've met, are terrible at naming files. In addition.. such a feature would need to check first if a certain namespace wasn't already in use (and if so difference it.)

Anyway.. in Ruby (when I get around to it,) such a "filename module" wrapper would not be able to take advantage of the extensibility of Ruby's file spanning modules and classes. This is one of the things that makes Ruby so dynamic and powerful.

jessejames

@dan rathbun said:

The newbies say they've read such and such a book, and still don't understand modules. The old-hands have read several books and coded for years and didn't really understand modules.

The fault lies with the tutorials and authors of the books. I cannot slap people around, because it's not their fault. (Slap the authors!)

Well i must agree Dan. If the teacher is teaching improperly then you cannot blame the student. I will admit my words could be taken harshly by the folks around here and that was not my intent.

I said before we need a style guide. Actually first we need a proper intro tutorial aimed directly at the SketchUp Ruby programmer. One which starts out banging the importance of modules into the heads of these folks. One which promotes a sensible style for all to follow. And most importantly one which is conspicuously placed and easily accessible by every SketchUp Ruby newbie. I would love to be a major player in bringing this into reality.

But we need not stop there. We can gather all the "community" scripts and re-write them in proper style. We can also (if our voices are loud enough) force Google to open a Official Scripts Repository. They don't need more Google employee's to Run it we can do this. We can't just put this info only at SketchUcation, or only at SketchUp group, or whatever. It MUST be at one official location so every new user can find scripts that are...

written in a high quality using modules.
bug free (as possible).
combined (where applicable).

This is my dream. I hope we can all agree about the benefit of such a system. We need to stop all the pessimism because we CAN do this. Remember the component browser back button issue? Yea, we made Google fix that conundrum and we can do it again. There is power in numbers that cannot be denied by even the most powerful corporations or goverments. When we speak with a united voice they will have to answer.

@dan rathbun said:

Well.. guess what? People are impatient. They don't read the advanced book, or take the second semester course. They jump in and start hacking, and run smack into "coding walls" because they think they are assigning values to variables, instead references that point at objects.

Exactly!

@dan rathbun said:

The filename namespace feature of Python I don't care for, and would not want it to be added to Ruby, UNLESS it was applied ONLY in the event a script was not explicitly module wrapped within the code. (But I can do this with my planned ObjectSpace Police plugin.. it's on my list, believe me!)

Ok i can accept that, can we make it happen though?

@dan rathbun said:

I'm wary about automatic filename namespaces as 80% of everyone I've met, are terrible at naming files. In addition.. such a feature would need to check first if a certain namespace wasn't already in use (and if so difference it.)

That seems to be the easier part of the problem!

@dan rathbun said:

Anyway.. in Ruby (when I get around to it,) such a "filename module" wrapper would not be able to take advantage of the extensibility of Ruby's file spanning modules and classes. This is one of the things that makes Ruby so dynamic and powerful.

Well thats true because Ruby does not have Python's import mechanism. Just FYI you can span multiple files with one program. If you could not Python would be useless. You just import what you need into the main script namespace. Anyway (back to Ruby) Could we somehow emulate import?

Dan Rathbun

@jessejames said:

Well thats true because Ruby does not have Python's import mechanism. ... You just import what you need into the main script namespace. Anyway (back to Ruby) Could we somehow emulate import?

Hell yeah...!

The same way Google does the rbs import but without decryption.

I was going to name the method ".parrot" and add it to module Kernel, that way it would be global.

I'm willing to take suggestions for alternate names, if parrot sounds too silly. (Be sure to check the methodname index at: http://www.ruby-doc.org/core/ to both be Rubyish and not use name(s) that are traditional for some other action, like "inject" and "insert" which are used for Enumerable object methods like Array.)

But basically you just open a file and read it into a string object.
Then pass it to eval (or module_eval or class_eval,) within the calling context (aka scope.)
There are a few search & replace tricks (ie, FILE, etc.) that need to be done before the eval, to simulate a normal load. But really it's not that complex, and wouldn't be that long of a method.

There's also a 2nd argument to eval that allows the imported script block to be evaluated within any scope if you pass a binding.

Dan Rathbun

@unknownuser said:

I said before we need a style guide. Actually first we need a proper intro tutorial aimed directly at the SketchUp Ruby programmer.

Well .. the forum [info] and [sticky links] posts are really a stop-gap, quick and dirty means. Temporary at best. (We can have only so many sticky threads.)

There is Tutorial Page Space here at SketchUcation:
http://www.sketchucation.com/tutorialsa/
(A couple Ruby scripting Tutorials in the Advanced "classroom.")

And a dedicated Tutorials Forum:
http://forums.sketchucation.com/viewtopic.php?f=18&t=8767#p52652

..with a Ruby Tutorials "chapter"
http://www.sketchucation.com/forums/scf/viewtopic.php?f=18&t=8767#p52665
(and a whoppin' total of 2 posts.)

Dan Rathbun

@jessejames said:

Anyway the real reason i replied is because i would for you and I to create a nice WORKING example of the very nested module system you are referring to. And what better example to use than all the script in the default SketchUp examples folder...

animation.rb

attributes.rb

box.rb

contextmenu.rb

linetool.rb

selection.rb

I already did a quick and dirty "wrapping" of the box.rb example (I might change the namespace names if I was to go at it again.) I had to do it quick because some people wanted to use the example and it didn't work because (why else?) it was running in the ObjectSpace and it and the "make_pano_pm.rb" plugin (both by Google,) both defined a create_box method. The second redefined the first, so box.rb did not draw it's boxes. (What an example, but it serves as an example of clashing code.)
I don't think I did much reformatting (I didn't want to change it too much, and I know I broke indent rules.)
Plugins Forum: [Example] box.rb version 2.0.0

thomthom

@dan rathbun said:

There's also a 2nd argument to eval that allows the imported script block to be evaluated within any scope if you pass a binding.

That would have been useful if SU's loader for scrambed plugins allowed that.
I ran into problems when I created an SketchupExtension that loaded an .rbs file - everything, got loaded within the SketchupExtension namespace. Had to use an unscrambled proxy loader to work around that.

thomthom

@dan rathbun said:

Well .. the forum [info] and [sticky links] posts are really a stop-gap, quick and dirty means. Temporary at best. (We can have only so many sticky threads.)

Yes - there used the many more - now they are moved into this sticky: http://forums.sketchucation.com/viewtopic.php?f=180&t=10142
Unfortunately it's not obvious resource to find.

jessejames

@dan rathbun said:

@unknownuser said:

I said before we need a style guide. Actually first we need a proper intro tutorial aimed directly at the SketchUp Ruby programmer.

Well .. the forum [info] and [sticky links] posts are really a stop-gap, quick and dirty means. Temporary at best. (We can have only so many sticky threads.)

Ah yes, the ol' multiplicity at work again!

Multiplicity is the hobgoblin of learning recourses. People just give up (rightly so) if they have to search through mountains of dispersed data. We need to gather all the data available into one wiki page (or whatever) that will serve as a single "simple to use" resource for the noob.

jessejames

@dan rathbun said:

Hell yeah...!

Now you're speaking my language Dan!

@dan rathbun said:

I was going to name the method ".parrot" and add it to module Kernel, that way it would be global.

Hmm, parrot is interesting. And lord knows i parrot off about Python all the time. However the word lacks an intuitive-ness for the action it implements. I don't think you'll find a better word than import.

thomthom

I think there used to be a developer wiki - but I think I saw it when I first joined SCF. Can't remember or find it now. In any case it fell into disuse.

Jim did create an alternative to the official API docs, http://code.google.com/p/skx/wiki/ClassIndex one that we could edit ourselves. Which I find more useful than just posting comments and twiddling thumbs, waiting for it to be acknowledged.
Haven't had time to use or work on it, but it would be good if he had that, and a wiki at one joint location.

It has bothered me that so many resources are wedged in between all the questions and general discussions.

The forum is great for gathering knowledge, but no good at organizing it.

jessejames

@thomthom said:

Jim did create an alternative to the official API docs, http://code.google.com/p/skx/wiki/ClassIndex one that we could edit ourselves.

Well my hats off to Jim although i looked over the doc and not much is there. I fear it will suffer the same fate as all the other docs and resourses -- a slow and agonizing death! Multiplicity and mediocrity are very prevalent in the SketchUp Ruby world today. We mush reign in this madness! Too long have stood idle whist the castle is laid siege. We need to yelling with a united voice daily...

Google we need an official Script Repository!
Google we need and official tut that can be edited by members!
Google we need official docs that can be edited by members!

... and we need all this information centralized yesterday!

@thomthom said:

Which I find more useful than just posting comments and twiddling thumbs, waiting for it to be acknowledged.

Is this comment directed at Moi?

@thomthom said:

Haven't had time to use or work on it, but it would be good if he had that, and a wiki at one joint location.

Wrong! We cannot keep up this multiplicity. We must force Google to do what is needed. You just wasting you time creating more sites that no eyes will see. If you have a suitcase full of money buried in the back yard but you forgot where you buried it then you really DON'T have a suitcase full of money do you?

@thomthom said:

It has bothered me that so many resources are wedged in between all the questions and general discussions.

Yes this too is a major deterrence to learning. Heck i was reading an announcement thread about a new script that had like 200 replies and many revisions to the script. After an hour of reading i just gave up. I could not even find the proper version in all the noise. It would be wise to allow an "announcer" to edit the very first post of his "announcement" indefinitely so he could update links to future versions or add more comments TO THE VERY FIRST POST INSTEAD STINGING INFOMATION THROUGHOUT 200 POSTS . Let the following string of thread[2..-1] answer users questions but keep the first post as an editable informational only post.

@thomthom said:

The forum is great for gathering knowledge, but no good at organizing it.

thomthom

@jessejames said:

Is this comment directed at Moi?

No - it was directed at the current system of the API docs. We have a long thread here with comments on the API docs. Which on occasion is read by Googlers which in turn make adjustments.
That was before they added the comment system on the API pages - where it was requested me made comments there. But response to our comments has been slow.

@jessejames said:

We must force Google to do what is needed.

There's a problem here - we don't have much power to force Google to do anything. If one can make Google buy into an idea - it's something that'd be a dreadfully slow process. Doing it yourself seem to be the only thing to get stuff done.
All though I agree that there's no point in yet another site/resource project falling into disarray.
However, I do believe that our previous attempts might have been a bit over-ambitious. Starting of with a too big of a task. Starting off with something smaller and evolve that could work better.

@jessejames said:

Yes this too is a major deterrence to learning. Heck i was reading an announcement thread about a new script that had like 200 replies and many revisions to the script. After an hour of reading i just gave up. I could not even find the proper version in all the noise. It would be wise to allow an "announcer" to edit the very first post of his "announcement" indefinitely so he could update links to future versions or add more comments TO THE VERY FIRST POST INSTEAD STINGING INFOMATION THROUGHOUT 200 POSTS . Let the following string of thread[2..-1] answer users questions but keep the first post as an editable informational only post.

What plugin was that? People can edit their own posts.
The normal convention here at SCF is that the first post contains the updated most recent version of the script. Pretty much all topics for plugins adhere to that.
A more recent discussion has been in regard to the visibility of the download link - a Download button graphic making it easier to spot the download link. Something some authors already use and something I will be updating my posts with.

Dan Rathbun

Wow this thread is all over the place.. but interesting.

Jim's Wiki API is an experiement. I played with one of the ConstructionPoint class, and came to the conclusion, it's just way too labor intensive. It relies too much on people following a set of style rules.

I did an automtic API some years ago using CSV data and HTML Tabular Data Controls that auto generated the API page. I wasn't satisfied (although it worked.) I always wished to update it to XML. Add the entries into the xml would be via a webform (check boxes, cut&paste boxes, etc.) then later on the API doc (either web or CHM,) would be generated from the XML (however PHP, RUBY take your pick.)

Editing would be similar, the method data would be displayed in an edit form.

Anyway the style of the API pages would be controlled thru CSS, and all pages, classes, would be displayed the same.

Dan Rathbun

@morgan74 said:

Thanks Dan for this interesting topic. I was rewriting all my plugin's code when I saw this thread.
So the only thing I need to do to follow you is adding a "TOP_LEVEL" namespace to my modules.

But I have a question about adding methods to Sketchup classes :
I want to add a method to "Geom::Point3d", how can I use a special name ??

Here my current code :


> class Geom;;Point3d
>   def myFirstMethod
>     return(self.z*self.z)
>   end
> end
>

Dan Rathbun

@thomthom said:

@morgan74 said:

But I have a question about adding methods to Sketchup classes :
I want to add a method to "Geom::Point3d", how can I use a special name ??

Here my current code :


> > class Geom;;Point3d
> >   def myFirstMethod
> >     return(self.z*self.z)
> >   end
> > end
> >

It's impossible to be 100% sure no one else implements a method of the same name as your when you extend a shared module/class. But if you for instance prefix with your initials you decrease the likely hood that your method is overwritten.

Personally I don't extend the base Ruby and SketchUp classes because of the potential of name conflict. (Doesn't look as good - but it's safe.)

jessejames

Hmm, i was wondering when\if these posts would get moved.

PS: if you guys need a easier hint to the 1264 thing send me a PM. I fear i may have set the bar too high!

Dan Rathbun

@jessejames said:

Hmm, i was wondering when\if these posts would get moved.

This is an example of people who just cannot follow instructions. (sigh!) And then compound the error, by posting AGAIN, to acknowledge he sould not have posted there. (I shake my head in wonder..)

It just shows that the forum environment is not so good for tutorials. Even the dedicated Tutorials Forum allows reply posts. I wish we could lock our own topics such as my [info] thread.

But at least I tried...

Dan Rathbun

@jessejames said:

Anyway the real reason i replied is because i would for you and I to create a nice WORKING example of the very nested module system you are referring to. And what better example to use than all the script in the default SketchUp examples folder...

animation.rb

attributes.rb

box.rb

contextmenu.rb

linetool.rb

selection.rb

Well yes I have been thinking about this.. but there are isssues.

I just know that some newbies are going to tweek, change and update the examples, without changing the namespaces. The examples need to be in some 'Google' namespace, as opposed to MY examples which would be in my namespace. These 'examples' I don't think would be sub-namspaced under the normal "Plugin" namespace ::PINE, but in an ::EXAMPLE namespace. (Most are not "true" plugins anyhow, more like code snippets we are supposed to paste into our own plugins.) I haven't yet finalized what the proper organized namespace trees should be, but I'm semi-close to publishing a proposed "Community Standard."
I have a huge list of my own projects I'm working on, or want to work on. (Some I've had to put aside, because they will rely on another project; or there's some bug in the API; or some missing feature not in the API that I will need. Anyway I either must wait until the API is updated, or create the functionality myself, propbably in C code.)
There is an issue of compensation. These scripts are the intellectual property of Google, although they have released them under terms close to the language of the MIT License. Yes, I would be helping everyone in the community, but ALSO, one of the largest software corporations in the world. I need income! I have bills, and am not employed. (The unemplyment rate here on the Florida Space Coast, is high and getting higher with the end of the Space Shuttle program.) I'd love to whip the Examples into shape. I'd love to correct every typo and missing argument description, etc within the API documents. But technical documentation is what I do for a living, and I feel that I should be paid, even if in the short term it's a discount payrate (I'm not greedy, and my expenses are low.)

@jessejames said:

The bad thing about a system like this is the fact that if people find it too confusing to implement they will just choose to be lazy instead -- and the last thing we need to do is help spread MORE laziness around this group! I always say a working example is the key to understanding systems like this.

True.. but there is also immense value in this. Last week one of the newbies I've been mentoring, PM'd me to ask for just this same thing. He wished me to provide him with a working skeleton of a tool plugin, into which he could paste his Tool class definition. (He even put a "## my tool code goes here" comment in his outline.)

I spent three 10 hour days putting together just such a skeleton, and then realized I could not keep doing these things. That is between 500-1000 dollars of work (depending on what you think the payrate should be.) I took a break, went on a walk, thought about it, and came to the conclusion that I need to genericize the code, AND implement it as a "Plugin Builder Wizard" (which would be a plugin itself.) Think about how a Software Installation Wizard works, and you'll get the idea. Sucessive forms, with choice controls (checkboxes, etc.) and the person would either use an "import file pathname" box (with a 'Browse' button of course,) OR a "paste code here textarea." (Their choice.)
So that's what I'm going to do with that project. But this cannot be free. I must have some kind of income from it.
Either individual license, or some entity, (commercial or benevolent,) needs to purchase it from me, for the salary-time I've put into it.

To complicate it a bit... I had to stop work on that, in order to resume my project to update the Sketchup Extension class as the "wizard" project will require it. I had already revised the Extension class to v1.1.0 back in January, and have been running it since (but did not release it.) It was only a few simple, minor changes.
This update will be v2.0.0, and will have major changes, BUT also be BACKWARD COMPATIBLE with v1.0.0 (the original un-numbered Google release.)
In addition I have some features I want to put in there, but they may need to wait for v3.0.0 or I'll never get it (or my other projects) finished.
This also has the same compensation issues like I had stated above. How to release it? I will have 2 weeks (say 100 hours invested in v2.0.0,) and really need to be paid for this somehow. Either Google buys it and they release it, OR I need to convince users and developers that it's a good thing and pay some small token license fee. (Somewhere between one and five dollars US.)

jessejames

@dan rathbun said:

Well yes I have been thinking about this.. but there are isssues. [...snip...]

Ok Dan, let me make sure i follow you. I going to summarize your post and tell me if i am correct...?

You want to create a "namespace manager" plugin (for lack of better term?) that works like a typical installation wizard. A user of such plugin would create a script by writing code in a "toplevel" manner without worring about modules or even nested modules. THEN they would run the plugin which would auto wrap their code into a proper nesting of module namespaces with their name being the toplevel module space. So in the end, the scripter no longer has to worry about the confusing aspects of Ruby modules and can concentrate on writing usable code that will be safe from invading outside namespaces.

Is this correct?

Hey, this plugin may even work nicely on a nested folder structure of scripts in which to base it's "module nesting" on..? You create a toplevel folder with your name, then maybe a tools folder full of tools, then maybe a lib folder, and on and and on.