Hi, Yes, this is why it works now⦠but I think it would be good to be more uniform. I remember that there where some non-standard uses of SharePool subclasses in native boost at some point, so it is not obvious that these classes are different.
On 20 Sep 2016, at 13:59, Clément Bera <bera.clement@gmail.com> wrote:
Are SharedPool supposed to be instantiated ? Why did you need to instantiate a SharedPool ?
I only use them (maybe mistakenly) by setting with class-side methods the default values of the SharedPool class variables, then use the poolDictionary: keyword to access those variables values from other classes. I thought that was the only way they should be used. Please explain me the other use-cases for a shared pool.
On Tue, Sep 20, 2016 at 10:38 AM, Nicolai Hess <nicolaihess@gmail.com <mailto:nicolaihess@gmail.com>> wrote:
2016-09-19 16:02 GMT+02:00 Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>>: This is probably my lack of understanding but I found this surprising behaviour....
I was trying to add a method to a subclass of FFIExternalEnumeration and it was not recognising classes. I traced this back to SharedPool which can be demostrated by trying to save the following method...
SharedPool >> test1 ^Object
reports... "Unknown variable: Object please correct, or cancel:"
Any insights?
I think it is a bug. SharedPool implement some special lookup to make the SharedPool variable lookup work. But it seems this conflicts with the variable lookup for globals.
cheers -ben