Need to do something
Daniel Vainsencher
daniel.vainsencher at gmail.com
Fri Oct 14 03:40:19 UTC 2005
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
More information about the Squeak-dev
mailing list
|