First thing - thanks to ortseam for your observations about multiple instances of the SAME plugin - I hadn't notice that. Knowing the nature of the beast is the most important step of avoiding any problems.
So is this a problem? Depends what you want to do, I suppose, but global variables are generally treated as a last resort even in general Ruby programming - if the value you want to store really is "global" in nature then there should be few issues with scope.
However, with class variables, it could be more of a problem - they're very often used to keep a tally of the number of objects of the class (e.g. how many notes am I playing), or a store for "most recent" values - things that really need 'sand-boxing' between plugin instances.
In cases like this, the only real choice is to use internal links to route the "unique" objects around, and ensure their scope.
It can also be a problem where a class or module has only class methods and is effectively used to provide a "single instance" object.
Nubeat7 wrote:but does this mean that we cannot use classes?
We sure can - more easily since the changes made with v3.0.3.
Apart from a few corner cases, most things can be written without the need for class variables - so most of the time we are using classes just to give us some nice object instances to play with.
The big problem before was that if ANY two plugin defined the same class, the first once would get all of its methods re-defined by the second - so if the two classes were defined differently, plugin one would instantly break.
Those days are thankfully gone, and in the case of two identical plugins, the classes would share the same definition, and redefining a class does not destroy any existing instances. That is assuming that no class variables have been used (unless sharing is your intention), and that the class does not "self-modify" its own code by dynamically re-defining methods.
Nubeat7 wrote:do we have to be careful how to write classes?
Oh yes! But maybe not for the reasons that you think.
The two problems that IMHO are much more common are...
1 - Name Space Say you make a new class called "MyObject" and use it tucked away inside one of your modules. You then take a fancy to something tasty from the forum - download it, put it in your schematic, and... BROKEN.
Without you knowing it, your new download has some Ruby in it - and the developer decided to use their own custom class called "MyObject" - which just wrote over your version. As many of us share the same obsessions with DSP, and use the same jargon, this is probably not as unlikely as we would like to think.
This is easily got around using name-spaces (though I often forget myself!). Simply define your class nested inside a 'module'
Code: Select all
module Trog
class MyObject
#CODE#
end
end
To use the class now, it must be prefixed with the module name, separated by two colons...
Of course, clashes can still happen, but by choosing what is hopefully a unique module name (our forum name maybe?), we can avoid treading on each others toes.
2 - Execution orderYou can't use a class until it's been defined, obviously. The order of initialising modules has strict rules, but they can be hard to follow in practice - after a bit of editing it is very easy to lose track.
The safest way to deal with this is to remember that ALL "init" methods are parsed before any events can happen. Arranging the code so that custom classes don't need to be called during "init" or "loadState" ensures that they will definitely be available. If you do need to initialize a value, a quick and easy way to do it in the main code is...
"||=" is a funny syntax, but in practice it means - IF this variables already has a value THEN keep it ELSE do the '=' assignment. So you get a new value the first time around, and then after that it does not get touched.
You still need to take care if there are dependencies between several classes (classA uses objects from classB) - to be sure, the easiest thing is to define them all in the same RubyEdit (an external code editor is useful for this - the FS one gets very slow after a few hundred lines).
RJHollins wrote:...rather involved dissertation that glazed my eyes over
He he, sorry. done it again
Just be thankful I don't live close enough to corner you in a bar and chew your ear off!
)
