[talk] Using Ruby Modules
-
@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. -
@thomthom said:
What plugin was that? People can edit their own posts.
Hmm, i'll give a clue... the sum of his name is 1264. I'll let the advanced readers decifer the meaning
PS: I'm just glad it was not 666
-
@jessejames said:
@dan rathbun said:
Well yes I have been thinking about this.. but there are isssues. [...snip...]
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.
Yes.. and NO. There would be a "Coder's Config" feature (dialog) where they set up defaults (name, company, Location, TopLevel Namespace, etc. etc.) but these defaults should be able to be overriden on a project basis, if say they were doing contract work for other than themselves (ie: another company.) So yes.. there ARE project management aspects.
And there would be Namespace Managemnt aspects, as some prolific coders are likely to subdivide their namespace into Catagorical subnamespaces (Anim, Export, Import, Report, Tool, Utility, Widget, whatever and however they'd want to organize their products.)
But it is really a "Proper Plugin Code Generator and Functionality Adder."
@jessejames said:
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.
Yes.. but with flexibility. (I'll just say that [for future possibilites,] they'll have the option of nesting their TopLevel namespace within other namespaces, even nested ones.)
More important. What I was speaking of in the previous post... is much more than a simple wrapper. It is specifically aimed at Tool class, and auto generates Extension loader scripts, optional Smustard Compatible Menu Scripts, Normal Menu Scripts, Toolbar Scripts, etc. It more than just "wraps" the raw tool class code, it also adds management functions, auto unload functions. It takes care of "doing it the correct AND safe way", ie it takes over the setup of the menu / toolbar command, so it's done correctly without creating a zillion uneeded tool objects every time the menu is clicked, etc. It sets things up so a coder can "publish" a safe tool call for other poeple to call (from another script, or a custom toolbar, etc.)
I suppose it could also work for normal non-plugins like Importers / Exporters etc. I'll just need to keep that in mind.@jessejames said:
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.
More exactly: "code that will NOT invade outside namespaces." (Meaning that crap scripts can still poop on the Objectspace, but it won't then do much more than waste memory. I still hate poop methods in Object getting inherited by every module and class.)
You are actually describing another item on my todo list. The "wrapper". (A linear command script really does not need a wizard; I've already shown in the forum how to put a couple of module blocks around them.) There's the possibility someone like you and I want to autowrap all code in our plugins folder, rather than manually edit every script we download.
And.. a proplific coder, may want a batch utility to autowrap all his project folders, rather than do it manually.
I may be speaking of several separate utilities here.@jessejames said:
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.
Yea you speak of a project folder and it's subfolders, such as we'd use with MS Visual Studio. They would contain the "raw" code snippets, and the Wizard would output the "distro" files in folders beneath the project's "distro" folder (which has a "plugins" folder.) Any file (a Extension registration rb,) that needs to go in the Plugins folder, would be put in the "distro/plugins" folder itself. From there it's manual copy to the real plugins folder (for your own testing,) or zip the fake "distro/plugins" folder for distribution/posting.
-
Of course the next campaign.. when we get everyone to wrap there code.
Is to get them to change their $vars to @@vars.Like $my_specific_plugin_menu_is_loaded
-
I use that syntax Dan. As far as I know, I was the first to try to make multiple plugins all work under the same main sub-menu, so as to not clutter the plugins menu.
If you have a problem with my coding, you can always PM me, or mention it in a specific plugin thread. But generalizing about all us noobs with bad habits or pros with bad habits, and talking bad about many of us who are trying hard to contribute is just bad taste. Knock it off.
Chris
-
@dan rathbun said:
Of course the next campaign.. when we get everyone to wrap there code.
Is to get them to change their $vars to @@vars.Like $my_specific_plugin_menu_is_loaded
Dan you bring up another very important point. Too many folks have this knee jerk reaction to create a global when they should be creating either class level or instance level variables. And i don't think they realize the danger of such behaviors. There is a reason why we feel pain, it both protects and teaches us.
I am starting to think that you should be the captain of this lost ship. Too many bad habits are propagating throughout this community. Someone needs to step up and say enough is enough already!
-
@chris fullmer said:
I use that syntax Dan. As far as I know, I was the first to try to make multiple plugins all work under the same main sub-menu, so as to not clutter the plugins menu.
Thats not even what this thread is about Chris. We are talking about namespaces here NOT how many Plugins Menu "commands" your script adds. Your inability to understand what we are talking about is the root of the problem. I don't blame you for learning how to script in a poor manner (namespace wise!) i blame Google and the other pros here who have not stepped up to the plate and made the tough decisions for all of us.
@chris fullmer said:
If you have a problem with my coding, you can always PM me, or mention it in a specific plugin thread. But generalizing about all us noobs with bad habits or pros with bad habits, and talking bad about many of us who are trying hard to contribute is just bad taste.
Sorry Chris but that is NOT how a community works. If i have a problem with your coding style, or if Dan has a problem, or even if John Doe has a problem, we can and should voice our problem publicly. THAT IS OUR RIGHT CHRIS! You made the decision to release public scripts and your public scripts are available for our criticism. If you cannot handle the heat, then get your scripts out of the kitchen!
You act as if we are just making up lies and i can assure you that is not the case. The problems we speak of are very real and infect this community from top to bottom. Obviously the problem is real because you're acting out in a "knee-jerk" emotional way to real criticism. If we are lying then feel free to offer the truth and correct us.
@chris fullmer said:
Knock it off.
Don't you even dare try to use your moderator status to scare anyone away from free speech Chris. You will never scare me, I can assure you of that!
However i want you to understand that nobody is picking on you "personally". Heck, believe it not i like you -- even when your insulting me sometimes
. You have given much to the community however you missed something very important. Everyone in this group is guilty of writing poor Ruby code and I want to fix that. Even i have written poor Ruby code because i did not know any better. So we must reign in this madness or it will get out control and sink the whole ship!I would really like for you to get involved with this effort Chris. Bring some real discussion to the table and we can work it out. But instead of getting all emotional -- try to bring some logic next time.
-
Could you guys (me saying this "generalizing" for the time being) take a little break, go out for a walk in the fresh air and come back a bit more relaxed?
Programming, coding and scripting should not be a reason for such heated discussions.
-
@gaieus said:
Could you guys (me saying this "generalizing" for the time being) take a little break, go out for a walk in the fresh air and come back a bit more relaxed?
Hi Gaieus,
I don't think these discussions are heated at all. SketchUp modelers and scripters are by far the most laid back and good hearted bunch of folks I've had the luxury of dealing with. I admit that I myself over react to criticism -- it's human nature. Chris is a very good Ruby scripter and deep down he knows that what we are talking about is real.
-
RUBY VERSION ISSUE: The toplevel scope operator
Ruby v1.8.0 does not allow the TopLevel scope operator prefix, ie:
class **::**MyTopLevel::MyPlugin::ThisClassRuby v1.8.6 does allow it. It basically tells Ruby to start looking at the TopLevel for an indentifier, instead of backing up thru each nesting level from the current level. (It speeds things up. It's similar to telling a system to start at the root of a drive when finding a file.)
I've removed the use of it in the examples in the [info] thread, as many users will be running v1.8.0 on Win32, and not know how to update their Sketchup Ruby. Also if the script is evaluated at the toplevel [which is the norm,] the prefix operator is really not needed.
-
@gaieus said:
Could you guys (me saying this "generalizing" for the time being) take a little break, go out for a walk in the fresh air and come back a bit more relaxed?
Gaieus.. I DID do just that when I first read Chris' responce (the day he posted it.) I was shocked and a bit angry at being treated this way!
I am just trying to teach. I am not using cuss words, and try not use ridicule tactics. (I had a math teacher in high school who did that if she called on you and you gave the wrong answer. "(Snidely) Eww.. looks like someone needs to do more homework." I hated that.)
Let's look at what I said:
@dan rathbun said:Of course the next campaign.. when we get everyone to wrap there code.
Is to get them to change their $vars to @@vars.Like $my_specific_plugin_menu_is_loaded
I see very few adjectives in that post. Certainly no cuss words. I wrote it in a very matter of fact way... just making a statement.
Look at Chris' responce! Chris says (or implies,) I'm "talking bad about many of us who are trying hard to contribute" and that what I have to say is "in bad taste." Then he ominously declares "Knock it off."
I would indeed, 'knock it off', if he can provide proof he also required the other respected SCF members who have previously said the same thing, to also "knock it off."
from topic: $ versus @@didier bur said:
I also use globals but it is a bad habit, ... But it is a lazy way of retaining values for your dialog boxes for instance, .... One can avoid globals when using classes and methods, class variables (@@) and objects variables (@).
@unknownuser said:
never, ever use globals in Ruby - beside name clash conflicts (as Didier said) you will have a lot of problems debugging it when someone else (your script or other) changes and you don't know why. of course you can use trace variable and see the caller stack, but why shoot yourself in the foot ?
@unknownuser said:
So, ensuring that variables are only accessible and changeable by certain well known bits of your program is just to make your life easier. ... Thinking about who needs to be able to access variables is a good exercise before you even approach a keyboard to ensure you've thought things through. ... The flip side is that those who have worked on multi-million line projects adopt these ways or working for a good reason and not just for the hell of it.
@unknownuser said:
For persistent data for Dialog Boxes, you should use Sketchup.write_default and Sketchup.read_default. The keys and values are stored in the registry (Windows) and the plist (Mac).
@tig said:
For a dialog's default values that you want keeping from session to session within a particular model, I write them as attributes to the model itself: ...
@unknownuser said:
So, there you have it - three solutions that avoid globals:
- Sketchup.read_default and Sketchup.write_default (persistent across SketchUp sessions and models)
- Attributes (persistent within a given model, between sessions)
- Class variables (@@variable) (persistent only within a SketchUp session)
All these things were said almost 2 years ago. The only thing that has changed is it's me saying it.
Chris also says that I'm "generalizing about all us noobs with bad habits or pros with bad habits..."
Well yes I may be.. but what am I supposed to do? Create a "Wall of Shame" thread, and start posting specific examples and naming names? That would embarass people. That is NOT my style.It has been done before... and noone said much about it. (Apparently because it was true.) It also seems that some commercial developers publish a list of scripts that cause conflicts with their products. (I think that is their right.)
I would rather generalize, than shame or embarass any certain person. If my arguments can convice someone to change their ways... then they will know themselves who they are, and whether they should should change their ways. ThomThom admits he's constantly changing his code for the better, but of course usually at the next revision. (He can't just snap his fingers.) I never said it should be done before any deadline.
The sadest part about all this... I clicked on Chris' plugin link in his signature line, and checked his list of plugins against my plugins folder. I've never downloaded any of them, so I can never have seen any of his code.
The statement about globals I made.. was prompted by someone else who sent me a code snippet, that had a global in it. That person probably learned it from seeing someone else's code.
I'm not going to name the noob, ... and I'm certainly not clairvoyant. There's no way I can possibly know who's code they learned it from.
Well.. I guess Chris wants to take credit for spreading the use of globals for submenu handles.
@Chris, Sorry if I inadvertantly struck a nerve Chris. Really... I'm not trying to make you angry. I'm trying to get you to see the better and easier way.
If you use a TopLevel "Fullmer" module (or whatever you want to name it,) your global $vars can just become module @@vars and they will serve you the same way. But then, they can never clash with anyone else's variables: global, class, module, instance or local.
Just as you can create getter and setter methods for instance @vars, you can create module getter and setter methods for @@vars.
So your Fullmer module can have Fullmer.submenu and Fullmer.submenu= methods that get and set the @@submenu variable.
Any plugin submodules can do the same thing, but each for their specific menuitem: @@menuitem, .menitem and .menuitem=
The bottome line is ... I tend to teach. I teach the right way. I will not tell anyone that a way is OK if not the right way.
It's a free country. Do what you want on your own computer. Do what you want in your own scripts. I dont have to use them.. OR I can modify the ones I may wish to use myself. No big deal.
Hey ... you don't need to even listen to me, or read what I say. But you absolutely DO NOT have the right to censure me when I speak the truth; or supress my freedom of expression if I'm not being profane.
I will apologize if I have let my exasperation and frustration with the state of Sketchup things (API etc.,) cause me to be sarcastic in some of my posts. Sorry for that.. I know I've done it.
I think I deserve an apology as well.
-
@Dan - I am sorry, I see now its all my fault. I saw your example line of code and assumed you must be pointing me out directly, because that is precisely my code. It is also virtually the only global I use, because I DO try hard to write clean code that won't mess up other people's scripts. I've used all those other tips you mentioned, because I don't want to be the one that messes someone elses code up. That precise example, of the global variable, is one I used a global on because that is how @Last had done it.
Anyhow, none of that matters. I'm sorry I came off so abruptly. I really thought you were calling my out directly. Even if you were, I should not have been so rough.
I did like the solid bit of example you provided. That is ALWAYS welcome.
ok, ok, back to the regularly scheduled thread about Modules...
-
Discussion of Wiki purpose and motives moved here.
Advertisement