$ versus @

[tbd]

• replace all arrow codes with constants - e.g. $leftarrow -> LEFTARROW
• replace rest of globals with class variables - e.g. $value -> @@value

tested and it works (retains distance between calls of tool)

[AdamB]

The original question was about why bother using anything but globals.

Given at the end of the day its just bytes in memory, why do all these pesky computer scientists keep harping on about using locals and scoping stuff?

Well, at the end of the day, it is just memory somewhere. But as programs became more and more complex the opportunities to shoot yourself in the foot and introduce bugs into the logic of your programs became more and more common.

So rather than have to make correctness assertions about a million lines of code, computer scientists started breaking down large programs into small self-contained pieces of a tens of lines of code that were guaranteed to have no 'side effects' outside themselves. Having shown the individual functions were correct, they could then move up and start making correctness assertions about groups of functions and so on. Its called a 'hierarchy of confidence' and without it you'd simply never be able to get big software projects out the door.

So, ensuring that variables are only accessible and changeable by certain well known bits of your program is just to make your life easier.

Ditto laying out your (Ruby) code with rigid rules about formatting/indentation. It just helps spot errors. Ditto naming variables that give a hint about the meaning of the variable. Ditto naming functions to reflect what they actually do and not having 'hidden magic' they do on the side..

So, if you want to use globals, and put all your Ruby code on a single line with no spaces. Go knock yourself out - you are free to do so. Its just making things hard for yourself - but each to his/her own.

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.

Having said all that, if you're writing a 10 line program and want to use globals because you've got a few minutes to bang some code out - don't have a guilt trip about - we've all done it.

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.

And lastly, for compiled code in C++/C# etc, using locals and avoiding globals will often results in the compiler generating faster code for you because it can rely on just the small set of local variables changing not anything and everything.

Phew,
Adam

[Jim]

@unknownuser said:

• replace all arrow codes with constants - e.g. $leftarrow -> LEFTARROW
• replace rest of globals with class variables - e.g. $value -> @@value

tested and it works (retains distance between calls of tool)

So, should we be creating new instances of a Tool each time, or referencing the already existing instance? (Instance level variables will also continue to exists for the life of the session, if you don't instantiate a new class every time the tool is activated.)

[AdamB]

I'd suggest always re-instance a Tool unless there is a compelling reason to make it persist.

As a general rule, releasing resources as soon as possible is a GoodThing, and secondly - and probably more importantly in a Ruby context, to ensure you don't carry references to Ruby objects and therefore stop garbage collection happening - worse still carry stale references to objects that have subsequently been deleted which tends to make SU jump into the azure blue sea of unallocated heap store and commit hare-kiri.

Adam

[tomot]

@didier bur said:

Hi,
But it is a lazy way of retaining values for your dialog boxes for instance, so user get the last values used.
One can avoid globals when using classes and methods, classes variables (@@) and objects variables (@).

I'm sorry but I cant let this topic die just yet. I have carefully reread all the
comments. Does this quote offer a solution to retaining values in Dialog Boxes?

[TIG]

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: when the dialog initialises it looks for their values, if they are not there it takes defaults - otherwise you have them saved on a model by model basis... For an example see my TextTag.rb.

.

[RickW]

So, there you have it - three solutions that avoid globals:

1. Sketchup.read_default and Sketchup.write_default (persistent across SketchUp sessions and models)
2. Attributes (persistent within a given model, between sessions)
3. Class variables (@@variable) (persistent only within a SketchUp session)

[todd burch]

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).

Todd

[tomot]

@rickw said:

So, there you have it - three solutions that avoid globals:

1. Sketchup.read_default and Sketchup.write_default (persistent across SketchUp sessions and models)
2. Attributes (persistent within a given model, between sessions)
3. Class variables (@@variable) (persistent only within a SketchUp session)

Thanks everyone; I took a quick look at TIG's, TextTag.rb. It appears to take a little bit more understanding of Ruby then just simply banging out a mass replacement of @ to $ or vise versa. Nevertheless I will try to implement
these attributes on an exisitng Ruby of mine.

[Matt666]

Hi all !

Just one question : How can you do when you have that :

class ToolsObsTest < Sketchup;;ToolsObserver
	def onActiveToolChanged (tools_object, toolname, toolid)
		[b]@t[/b] = toolid
	end
end

and this variable @t is used here :

module
  def
    [b]@t[/b]
  end
end

So the variable is not used inside the first class section, but inside the instance of a module section ???
To find variable, I use $....

How can I preserve variable value ????

[AdamB]

Just define your Observer class in the scope of your Module

module Foo

class ToolsObsTest < Sketchup;;ToolsObserver
   def onActiveToolChanged (tools_object, toolname, toolid)
      @t = toolid
   end
end

end

instance = Foo;;ToolsObsTest.new

[Matt666]

Hi AdamB !
Thak you for your answer...

I tried it but it didn't work for me... @toolID (variable name in the code) always returns nil....
here is the real "tree" of the code (including your advice)

module Toto
	class ToolsObsTest < Sketchup;;ToolsObserver
		def onActiveToolChanged (tools_object, toolname, toolid)
			@toolID = toolid
		end
	end
	###
	def self.act
		model.tools.add_observer(Toto;;ToolsObsTest.new)
	end
	###
	def self.obs(id)
		@toolID
	end
end

---

Do you know why your method doesn't work ?
Thank you !

[fredo6]

Matt,

The two @toolid are different. One is a Class instance variable, the other a Module variable.
If you want to track the toolid in module Toto, then use a method to set its value, which you can call from the class.
Note that normally, you might use a Module variable, with @@, (since module instance variables do not really have real application)

def Toto.set_toolid(toolid)
   @@toolid = toolid
end
def Toto.get_toolid()
   @@toolid
end

Fredo

[Matt666]

Hello Fredo6 !
Thank you for your answer ! It works great ! get_toolid & set_toolid are perfect !
Just one thing, @@variable doesn't work. Just @variable...

Thank you Fredo !