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 <[email protected]> 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 <[email protected] > <mailto:[email protected]>> wrote: > > > 2016-09-19 16:02 GMT+02:00 Ben Coman <[email protected] > <mailto:[email protected]>>: > 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 > > >
