Word of warning to developers

RickW

There are a lot of us writing scripts/plugins, and as our numbers grow, so do the odds that someone will write something that breaks something that someone else wrote.

So, some important items to remember:

Try to know what others are doing/have done - this isn't always easy, but some research and questions go a long way in avoiding conflicting class/method names. It can also prevent you from duplicating someone else's effort - why re-create method x when it's already been written? Just tap into it and go (with permission, of course). Sometimes, the already-written code won't do exactly what you want. In that case, you can either subclass yours and modify the methods (for classes, obviously), or write your own using a different class/method name.
Try to use unique names rather than common ones - for example, if you write a "ProgressBar" class, you will cause conflicts with any other "ProgressBar" class. That will make for unhappy users, as they try to get tech support for something the author says works just fine on his machine, but clearly won't work on their machine; and will make for unhappy fellow developers, who have to hunt down the conflicting script, locate the author, and try to work out a solution.
Encapsulate methods in a Module or a Class - within a class, you don't have to worry about method naming conflicts, and within a module, you can be less careful about both class and method names.
Test your work against as many other works as possible, and test them against yours - unfortunately, the burden of compatibility will more than likely fall to the second developer. However, if you send your script to other developers asking them to test for compatibility with their works, they'll most likely be happy to oblige (subject to their own time constraints, naturally). This will help keep the user experience (and your reputation) positive.

Just some helpful tips to hopefully keep this great collective creative work going smoothly...

Matt666

Hi Rick ! Thank you, I will pay attention to these items for future scripts !

@unknownuser said:

Encapsulate methods in a Module or a Class
Sorry but I don't really know how to encapsulate methods in a module...
Is there just one method to use Module ? I know this method (from Jim' scripts)

Module Test
  def self."method1"
    ...
  end
  def self."method2"
    ...
  end
end

And to call the script, we have to write 'Test."method1"' for example. Are we obliged to write the "self"?
Briefly, I do not know this method

Can you help me ?

RickW

The Pragmatic Programmer's Guide has some good information on modules.

Hope that helps,

Matt666

Thank you !

CPhillips

Come on. Spill it. What plugin did you find a conflict with?

todd burch

One of my paid scripts was broken by a free script. Names are being withheld until notification of next of kin.

Didier Bur

Gaieus

scottlininger

Another broad area of "wishlisting" is how we can best handle the problem of our scripts accidentally clobbering other people's. It's great that Ruby is such a flexible language, but we've all seen situations where two of us choose the same name for something and everybody loses.

RickW has suggested to me that we form some sort of "official" policy and/or repository for handling this problem, and for reducing code rewriting, so that we all benefit from the collective knowledge of the group, but as of yet I haven't pulled together a proposal for the community. What are your ideas?

Some possibilities:

Create an "official" means for extending Sketchup.rb, along with a versioning system, so that we can extend the base API.
Create some kind of name-spacing convention that we can publicize and encourage folks to use.

I'm sure these are things you've all been talking about (I'm still catching up on back-messages.) I want something that's easy for people to use, from novice ruby programmer to expert. If it's too hard for people to understand and adopt, then we're wasting our time... What do you think? I'm all ears.

solo

I am no coder so my opion is worthless however .... how about having all ruby's include the authors initials? IE adjust_textures_PJS.rb (hypothetical ruby)

Dik Harrison

Formally, I worked for a large government agency that developed their software internally, with development taking not only at development centers, but also at individual sites (170+), at least that is how it worked a number of years ago, now there is not much development going on now. Any way, back when everybody was developing or at least customizing for local use, each site was given a short code 3-4 letters that made their variables and routines unique. Using initials or some such would work in this situation, but a list of initials would need to be maintained, so that duplicated would not occur. Then a coder would simply add their code as a prefix or sub-fix to their routines and variables. For example, I would write a routine called something-wrh.rb, with a variable x-wrh. It would be up to me not to step on my own code.

TIG

@unknownuser said:

The precepts of the law are these: To live honourably, not to injure another, to give each his due.

As Gaeius's strap-line says [in pig Latin]...

i.e. Remember: Be nice to others. Don't mess others up. Give others due credit...

Gaieus

Hi TIG - yes, a bit off-topic but hey...

It's Institutiones Iustiniani 1.1.3

(I wrote my thesis in Roman Law at the Law School )

Jim

I have been using my initials as a module name to encapsulate everything I release, although I think sometimes little things slip through the cracks.

Would a shared Google Docs spreadsheet be good enough to claim and register namespaces?


        Name        |        Email        | Registered Namespace
Carl Coder          | ccoder@gmail.com    | Ccoder

scottlininger

Have people seen any errors from other ways that scripts mess with each other besides naming overlaps? For example, observers from script A are messing with the model before my observers from script B fire off?

todd burch

There have been right-click context menu issues with validation routines. The classic issue here is HouseBuilder causing a beep if installed whenever any right click was done. Not so much a conflict as an annoyance.

I remember an issue one time with some script extending a base class of Ruby (like NullClass) and it causing issues. Don't remember the specifics.

What should probably be promoted is script authors subclassing Sketchup classes to extend them, as opposed to just extending them.

tomasz

@unknownuser said:

Have people seen any errors from other ways that scripts mess with each other besides naming overlaps?

I've got two scripts on my black list.
1st place : Matchbox Plugin 1.1 by antantantant
Population.rb

class Array
  def * (n)
    temp = Array.new()
    i = 0
    if n.kind_of? Float
      each {|v| temp[i] = v*n
            i = i + 1}
    end
    return temp
  end
  
  def + (n)
    if n.kind_of? Array
      i = 0
      temp = Array.new()
      while i < [self.length, n.length].max
        temp.push(self[i] + n[i])
        i = i + 1
      end
    return temp
    elsif n.kind_of? Float
      each {|v| v = v + n}
    end
  end
end

Arrrrgggghhhhhhh..... !! Do NOT modify built-in Ruby methods, please!!

2nd place: Train Simulator 1.2 exporter by Paul Gausden
mstsx.rb

class Sketchup;;Color
	 def ==(c)
		 return (c.alpha==self.alpha and c.red==self.red and c.green==self.green and c.blue==self.blue)
	 end
 end

Modification of original SU method, which can : 1st - give different results than other Ruby programmers expect, 2nd - prevents != method to work correctly.

Those bugs makes my life and users of my exporter harder.

sepo

Matchbox is also on the Podium NO NO list.

deerwood

Hi all,

though I not yet had any name clash problem, may I suggest a rule adopted from the Java world? The essential idea is to qualify/prefix "packages" with something unique in our internet world. Namely the domain of the author, reversed, optionally followed by some more specific info.

So e.g. Jim's "jitter.rb" is qualified by "com_blogspot_sketchuptips" and the specific info beeing "jitter".

And Ricks "GoldenGauge" is qualified by "com_smustard" (or maybe "com_smustard_wilson_rick") and the specific info beeing "golden_gauge".

Following that idea the plugins working code would not reside any longer directly inside the "plugins" directory (unless it is an essential thing/library) but in some directory named after the domain inside "plugins".

E.g. Jim's plugins ALL reside in "plugins/com_blogspot_sketchuptips" and ALL of the Smustard ones are present under the "plugins/com_smustard" directory, optionally further down in a dir named after the author ("..../wilson_rick") or a project ("..../common" or "..../utils").

And, please, all other excellent plugin writers here around: I apologize to not have named you. But you'll get the idea, hopefully.

To call/activate such a plugin on startup of SU there must be a minimal Ruby script directly in the "plugins" dir, requiering the real code. These would be one liners, but then named after the complete path to the plugins code. E.g. "jitter" would have this Ruby in the "plugins" dir (named "com_blogspot_sketchuptips_jitter.rb"):


require 'com_blogspot_sketchuptips/jitter.rb'

But it should be easy to just call a script common to a domain, that does advanced handling of (sub)scripts to be included. That script then just requires, what the final user wants to have. These require scripts (down to any level of the dir hierarchy) could easily be tweaked by users, by just commenting out "require" statements.

Packaging of plugins into this hierarchie/concept is easy for every developer of plugins.

Every plugin's author is known/can be reached (as long as his domain is existent).

Cluttering of the plugins directory is reduced greatly, especially when the feature of just require'ing subdirs reqire scripts is used.

What do YOU think?

Best regards, deerwood

RickW

Interesting concept, and for creating Module names, it could work. However, locating files in subfolders by organization/author name conflicts with Organizer.rb.

Currently, Organzier allows users to create subfolders in the Plugins folder that then become submenus in the Plugins menu, with the scripts located in those subfolders likewise having menu items in the respective submenus. For example, you could create a "Draw-Create" subfolder, then move all scripts that draw or create geometry in that subfolder. In the Plugins menu, there would be a Draw-Create submenu, and each file in that subdirectory would be represented in the submenu. It's a fast way for users to clean up both their Plugins menu and Plugins folder at the same time, while grouping scripts by like function.

I think that a script that parses the new template file and can display the pertinent script information in a webDialog will go a long way towards helping users who want or need to know the author/contact information or version number to check for updates.