Avi Bryant wrote:
> On Oct 13, 2005, at 10:32 AM, Daniel Vainsencher wrote:
>> Note that the work needed to be able to share packages is exactly  the 
>> work required to make the update stream work - create a series  of 
>> loadable package versions that get (any image) from here to there.
>>
>> This is what makes the whole "images vs updates" thread pretty much  
>> bogus in my eyes. If we stop doing this work for some package, and  
>> just patch things up, we will probably never share that code with  any 
>> other image-lines that want to keep their own images.
> We don't yet have an update script that can take an arbitrary image  and 
> load Traits into it. Does that mean it's impossible to share  Traits
> with any image line other than the one it was developed in?
> Of course not.
Here we agree :-)

>  There are manual ways for an experienced developer to  
> integrate Traits into whatever image I give them.  There may be  
> challenges unique to any particular image, but they would certainly  be 
> solvable. 
Here we dont - the challenges for Traits are not unique for some 
specific image at all. Adrian and I have already created and run such a 
script, so while we don't yet have something I'd put on the update 
stream, we know what the issues are.

They are specific to Traits, but quite independent of the image - when 
you change the mechanism for adding methods, to use new methods, then 
those methods need to be loaded before any changes happen. This is true 
in any image that has never had those methods (true across images). 
Furthermore, from Stef's more recent example, this problem happens 
whenever you change any mechanism that is somehow involved in updating 
methods - such as drawing the progress bar... therefore its a technical 
problems that will happen in many cases. Feels very strange to tell you 
this - the solution in this situation is fixing the infrastructure, not 
smart people applying their brains every time, manually, for every image.

> And once solved, it's very likely that any further  updates 
> to Traits - loading new versions of the various Traits  packages - would 
> be much easier.  Maybe still a manual process in  some cases, but easy 
> enough that it could be done at regular  intervals.  And anyone who was 
> a client of that image line would get  that integration for free, by 
> downloading the newly integrated image.
So the person most qualified to solve the problem (the person that wrote 
the change) - now finds it impossible to help in the solution of this 
problem. This is because he doesn't even know about, never mind take 
part in the development of all image-lines.

Instead this work is thrown on image-line maintainers (for whom it takes 
time to understand the change) in a way they cannot share between them, 
so each wastes time on it anew...

> Capturing easy integrations with scripts is easy.  Capturing hard  
> integrations with images is easy.  Capturing hard integrations with  
> scripts is hard. 
Hard is what we haven't thought about enough.

> If we bias towards the first two rather than the  
> third, we have more energy for writing interesting code to  integrate.  
> What's bogus about that?
Two very simple things.
1. If you can tell people "you can probably always update your image, 
forever", they act in one way. If you tell people "you can update the 
image except when we don't feel like it" they act another way. They 
might never invest enough in their objects to make them worth the 
trouble of publishing, simply because they think they won't be able to 
keep them alive at reasonable expense.
2. And the tools never need to rise to a new bar. What is happening with 
MC right now, IMHO, is very valuable. Since we've met the issue of MCP, 
Stef, you, I, Andreas, we've all learned about what MC can and can't do. 
We're also learning about new requirements.

I think we shouldn't confuse the fact that the learning is somewhat 
painful with whether it leads to a better place...

> I enjoy solving hard problems, but not for their own sake.  If I can  
> see a way to be lazy and avoid them, I take it every time...
But at some point you realize that these are coming all the time, and 
its worth working once to kill them all - if the cost is reasonable.

Do you estimate we're not there yet for solving this issue of method 
dependencies?

Just as a quick sanity check, the following code does not immediately 
crash the image

firsts _ ProtoObject withAllSubclasses asArray collect: [:cl |  cl 
methodDictionary].
seconds _ ProtoObject withAllSubclasses asArray collect: [:cl |  cl 
methodDictionary copy].
firsts elementsForwardIdentityTo: seconds

So the atomic load method you suggested is probably not impossible.

Daniel