On 11/10/17 5:41 AM, Johan Brichau wrote:
> Hey Dale,
>
>> On 10 Nov 2017, at 14:29, Dale Henrichs <
dale.h...@gemtalksystems.com> wrote:
>>> The issue I encounter is that a class initialize method of a class in one package fails because of an undeclared dependency on another package.
>>> This did not fail when using the ConfigurationOf and I am wondering if class initialization is done on a per-package basis or should it also be postponed to after all packages have loaded when using atomic loadpolicy?
>> I actually don't remember this level of detail ... I would have imagined that the initialization is held of until the end, because the classes aren't even defined until all of the definitions have been defined ... presumably the problem is occurring because you expect the initializations to take place in a certain order and that order is not respected in atomic load ... package order is lost in this process ... controlling initialization order is on e of the reasons to use #linear load ... I suppose that there might be a way preserve package order for initializations ---
> The class initialization fails because a method defined in another package was not loaded yet.
> The initialization order does not matter in my case, I was just expecting the class initialization to occur after the loading of all packages.
This seems to be more of a bug .... it seems to me that with atomic
loads the initialization should be deferred until all definitions are
loaded (a stack from the failure should provide the necessary information).
The other possibility is there is still a project with a #linear
loadType present ... Metacello will honor mixed #linear and #atomic load
types, but when a #linear project is encountered I think the
initializations up to that point get fired ... perhaps this is what is
happening to you?
>
> I fixed it by moving the method because we had a circular package dependency anyway, so I’m not blocked by the issue right now.
> Just strange this one did not pop up until I tried our loading spec in a BaselineOf.
>
> If the atomic loading still preserves classhistories in Gemstone when classes are moved between packages, I’m fine with it.
>
>> I don't have a lot of cycles right now, to take on this project, but I would be willing to work with someone from your team to help with adding this feature to Metacello ... from 10,000 feet it looks like the atomic load directives build a package order postLoad list so I would think that package load order would be maintained for initialization ... but I know that problem with Seaside (#linear was created for Seaside, mainly) that the initialization need to be performed _without_ other classes being present --- do you happen to be trying to do this with Seaside? If so that is completely different kettle of fish ---
> No, it’s the Yesplan source I’m trying to move to git completely.
>
> Thanks for the proposal and sending a response on your travel (you are traveling to Smalltalks?)
> We’ll see what I can find and I will report back here.
>
I'm actually not going to Smalltalks this year ... I am working on an
internal project that has a deadline of today (for my part:)
Dale