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.clem...@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 <nicolaih...@gmail.com 
> <mailto:nicolaih...@gmail.com>> wrote:
> 
> 
> 2016-09-19 16:02 GMT+02:00 Ben Coman <b...@openinworld.com 
> <mailto:b...@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
> 
> 
> 

Reply via email to