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> wrote:


2016-09-19 16:02 GMT+02:00 Ben Coman <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