Dear thomthom, all,
@thomthom said:
It was just that what deerwood said sounded to me that, modules where to be used for a few methods, but classes if you had many. Maybejust me that read it odd.
I've seen often in scripts that classes has been used as purely encapsulation and never used as objects.
sorry for my late answer, I just had prepared a continuation of my earlier post ... and lost it completely in an editor (notepad++) crash 😞 !
Yes, you are right: if one invents a class with only class methods, it makes no real sense at all to instantiate that class, because the instantiated object(s) don't carry any state. The Java Math class is an example. It has a full load of useful class methods, e.g. Math::sin(), Math::cos() etc, all getting in the values to work on by providing them as parameters. But it has no state at all (and no instance methods). In Ruby one would normally use a module for that (independent of the number of modul/class methods, compare the Ruby Math module). But then, it doesn't harm to use a class. Just do not instantiate any objects from it and use it the same way you would use a module, just to have your own namespace.
Class/module methods do their work by accessing some commonly available information (e.g. Sketchup.active_model.selection) or some parameters or a combination of both.
Though there is more to tell about Ruby modules (later).
But the Ruby way of dealing with things is different. In Ruby almost everything is an object. Even simple things like integers are full blown objects. Try this in the Ruby console:
65 >> 65 65.next >> 66 65.chr >> A 65.next.next.chr >> C
You just invoked two easy to use methods on a simple integer number object. What is an object, then? Something having a state (a value or some values, individual to each object) and a behaviour (common to all objects of that type). Every integer object in Ruby has it's own state (that integer value) and a common behaviour (next always gives you a new integer object with it's value incremented by one). And chr spits out a 1 character long string object with the ASCII representation of the value.
Note, that both methods take no parameter at all ... they use the internal state of the integer object at hand.
It would be very inconvenient to have to define the common behaviour of something in all and every object of that sort. Thus OO languages (including Ruby) have classes to define the common code/behaviour for all things of that sort.
If the class is in place, you can later instantiate as many objects of them as you need. Every instance/object will have it's own state (using up memory) but share the same behaviour (not using up memory).
So, for now (remeber my loss of ready made explanations): if your plugin does not carry around some state (or you save them somehow externally in attributes) you might be fine with just using module/class methods.
Still to be continued ...
best regards, deerwood
