I’m certain we had a good reason to turn loadable shared pools into
classes. I think (but I’m not entirely sure) it had to do with ensuring
they had been properly initialized before executing code that depended on
the constants declared in that pool. Class initialization of a designated
class was TSTTCPW.

In other words, your shared pool should indeed be a class. It doesn’t
matter for using it, but it does matter for loading it reliably.

I admit I could be misremembering, it’s been quite a while.

–Vanessa–


On Tue, May 18, 2021 at 05:42 Marcel Taeumel <marcel.taeumel at hpi.de> wrote:

> Hi Christoph,
>
> > This error message does not make sense to me since MyPool is not a class
> > but a pool dictionary.
>
> You can use classes and global dictionaries as a shared pool.  From the
> system's perspective, it does not make any difference as long as
> #bindingOf: etc. is implemented. See class-side of SharedPool class. If you
> use a class as a shared pool in another class, the class variables will be
> shared. :-)
>
> ***
>
> Yet, I think you found a bug. Maybe this was the reason why "FFI-Pools"
> exists in the first place. So that it can be loaded before "FFI-Kernel" xD
>
> Best,
> Marcel
>
> Am 18.05.2021 13:21:34 schrieb Thiede, Christoph <
> christoph.thiede at student.hpi.uni-potsdam.de>:
>
> Hi all,
>
>
> while loading a class (MyClass) with an attached pool dictionary
> (MyPool) today using Monticello, I encountered an error from
> MCPackageLoader which states:
>
>
> Warning: This package depends on the following classes:
>
> MyPool
>
>
> This error message does not make sense to me since MyPool is not a class
> but a pool dictionary. But in MCClassDefinition >> #requirements, all #poolDictionaries
> are explicitly added to the list of required items. If I exclude them from
> this list, I get a warning "The pool dictionary MyPool does not exist. Do
> you want it automatically created?" later from Class >> #sharing:. Is this
> a bug?
>
> I also tried to manually add the pool dictionary initialization (Smalltalk
> at: #MyPool put: Dictionary new) into the preamble of the package, but this
> preamble is also evaluated too late (i.e., not before the dependency
> warning is raised. Also, this feels a bit too redundant to me.
>
> Do we need a new subclass of MCDefinition to create pool dictionaries
> automatically? Or could we just remove the confirmation dialog in Class >>
> #sharing: so that new pools will automatically be created, especially in
> non-interactive CI contexts?
>
> Best,
> Christoph
>
> <http://www.hpi.de/>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20210518/167384aa/attachment.html>