Is there a way I can make a method or a scope "static" or "global?" I’ve been looking around for such a thng but instead I’ve been dealing with lots of scoping errors. I’m in a poly inside another poly so the parent game is getting pretty nuts.
There’s no way to do that yet in the oo objects. The problem is that everything is explicitly instantiated at runtime in Max, rather than defined and compiled. Not totally off the radar though.
If you can describe what you’re trying to do, we may be able to suggest ways to handle it.
It’s also possible you are running into an oo objects vs poly~ bug. Does this seem familiar?
It’s not the poly bug. I wrote some abstractions to help me. here they are.
The thing I realized is that there is no such thing as static in max because "methods" get instantiated over and over unlike other languages. (not that this is your fault. Jesus Christ these things are a godsend)
Typically, in java, I was doing a lot of calling to static methods to do big stuff like "turn the whole thing off!" It would be nice to somehow, one day, separate the data, the audio and the methods like a "real" object oriented language.
sorry, that was a lot of geeky BS.
----------begin_max5_patcher---------- 397.3ocuTEsaBBCE8Y3qno6UlghfN2a66XwrfvcZWfBoT1by3+9n2Ba5BJMN zGfldusm64b5M2ctNzUEagJJ4QxyDGmctNNXHc.m18Nz73sIYwU3wnE0pLPQ 8LoD04bQydLGqMXYrJYCWr9EIjnLXGrX9DeORvCA3RT2exx16vSMnu5s6mc. 3lpgn62FMoHOGDHtTpNzdWW8OOKEf.9noJc0PAaMPIaJEPtyuKwqEBkHNGvj OI4wYcYLbR8YIXzFk5078iRzWrh+Eljok6k4TgyzKQFmxuemJpemJX7bkRIT BhzKzWFOOAMCV.ZMyYmySB62SXiXmBj.72a5UXSjfpVJt5Vi+vsK3UIL+y5M Su5dSE1rvlnj70qA4vNyH0YDEhKL+yI+fSLX4BjORNKdcs+YD0whoCOdjchG wAFOhPQy3h+NtGYiN9wxspnVlzIn15R9kPoPkhKhU7BwAmI7nyrgmlBhCUdN OsrfKTsTfrrWq2VFEZAiBtoLZpELJ5lxnHKXzr+AiZ1r28a.Sc03WA -----------end_max5_patcher-----------
----------begin_max5_patcher---------- 588.3oc2W10aaBCEF9Z3Wgk2sYQ9C9b2seGSUSTvK0UfAANaYsp+2G9XRaXK DPo.Kp2.xG7GuOu19X7ytN36KOHZvnuf9Fxw4YWGGHjIfSWYGbQxgz7jFnZ3 BQSSxNAdi8aZwAsM9wH+nToUIEBH5WqkI4G+R4dctPq+ckvNfXL5tSZTi7I3 CT1VRWX09BopsMvPy5BVknSePp188ZQp11SbRPaaPbF09Zq+FDMZK409WlAx o79G+bL9sN2pHn2olfu35Zdr457h+Gj6EZQNFL.eh44PjS89XgdPDfd.cBny VLzuM1A3wCM7yhBGeG.kLelAHtIfWONHCyAKF.HfCz3e744vHZ.J5hlVVTHT 1oF7UPlsKwmS+zKjIh4YzrGYB.Ddd.HyD.JwuZGk+YYZUsnRnxPMuA2hsfkN 5DM0tINDbMF47FUv7sd811T3108bp+3lh+haJOkiZxkoBD8Z7jMyX1MVTfM6 VLjpO7R9x.Gxw9H5KcqW5x5eYegu39RiYGzmnaqE580pw8lYJCRLrnHJ5RvO vw+j4C9VcIj+TX3WWK2sSTu3IRF+XTlO3JztSiFvbnimIAZFNWp96KK.isId eGqobec5Qp51UhnuN3YhFsTknkkpSpSbu57fLKSnNkyBYVUoTo6j.5tyN6MU E0RMhLhhL+ozJJonIHofd0YoUzTl1BWUE4O+dDOD9cYtOrKwKlAmA2qDkYuq Q68L86J8N4HXBbvVUmkOAE4upJZJaQ42bq9ndqZRioLsYt96MVpUu2w7VagW b+C2iMDO -----------end_max5_patcher-----------
Thanks. Obviously, we aren’t actively developing at this point (due to work committments), but the oo objects are not a dead project. It’s good to know that they’re in use and appreciated.
I’d given this some thought a while back, and the "static" keyword might make some sense in the context of a subpatcher in an abstraction, which is the closest thing to a class definition we have.
The way I think this *could* be handled is that you’d add [p @oo foo static] to the abstraction, then when the abstraction is instantiated the static patcher would be instantiated *once*, invisibly, and either removed from the instantiated abstraction or presented as a dummy object (possibly double-clickable, not sure about inputs/outputs). Any oo.calls into the static patcher would go to the invisible singleton.
This would also work for the proposed oo.alias in an abstraction, but not for a raw oo.method, since the method body is separate to the oo.method object – so you’d need to encapsulate as a static subpatcher and use an entry method to get a static method.
As far as static *access* goes, I’d expect static objects in an abstraction to only be accessible from within the abstraction (ie file scope). You’d need to define a separate public accessor method if you wanted to use them from outside an instantiation of the abstraction.
Defining something as static inside an ordinary patcher would be possible but pretty much equivalent to defining it private, since you’ll never have another instantiation of that specific patcher (only a copy). But as soon as you save it as an abstraction and instantiate you’d get static behaviour, which may be useful in development. Mattijs, are you watching this thread?
So much for theory. In practice, I bet it’s a whole nasty can of worms to implement…
I need a few more decades to think about this. John, you must have thought you were a glass of orange juice by the time you were done writing these.
A double clickable singleton object that loads a patcher one once and deletes it when the last [singleton myClass] object is removed would be useful. I can do that in java if need be. It can be a separate deal.
Maybe it’s because I’m javacentric but I don’t understand why the static methods need to be private. The reason I made the post is because oo.call paths are all relative. You can’t jump around in the hierarchy with static calls. so [oo.call myClass.lightSwitch.getOnOff] isn’t possible. If I understand the objects, in a sense, unless you want to go traversing up the hierarchy, you’re stuck private no matter what.
The solution as I see it, would be to add file names to the list of things oo.method could look up.
This way you could have [oo.call MainPatcher.circle.getArea] and you could call that from anywhere unless you explicitly set it to private.
… I think.
… I have no clue
… this makes my head hurt.
and yes. They are incredibly used by me. THANK YOU
Here’s a singleton object. It’s controlled by MXJ but calling the method should be just as fast as send and receive.
I’ll include it in the release of mat.abstractions
Mattijs and I had a few discussions about whether we should adopt Java’s access model. In the end we decided that Max has enough ways to make things public and/or global already, and the oo objects should enforce a private by default policy.
My interpretation of "static" access would be the same as C/C++ – file scope. A static member would be accessible from anywhere in the same file (ie class, ie any instantiation of the same abstraction), and shared among all instances of the file/class/abstraction.
With that in place, it *might* be possible for the oo objects to call class (file) methods directly, without visibly instantiating the class (though an instance would have to be loaded behind the scenes to do so). Conceptually, this might be stretching the "Max way" a bit too far.
And we don’t do global. If you want a globally accessible method in the top patcher, what’s wrong with the Max send/receive objects?
If you want to do that with oo objects, you either
A: traverse the hierarchy upwards to discover the method then store a reference to it, or
B: pass a reference to the method down through the heirarchy via oo patcher constructor args at startup. [oo.alias] will help with the latter when it is available – though I also had some thoughts about constructor args being automatically assigned to private member variables, which would allow their use in oo subpatcher args without any additional objects, ie [p oo_1 @oo mypatcher], where oo_1 would be the first argument passed into the parent oo patcher.
OK *this* makes a ton of sense to me… the easy way to do this would be to do [loadmess this]->[deferlow]–>[oo.call right inlet]–>[value reference id]
John thanks for indulging me, I learned a ton.