Michael van der Gulik a écrit :

> Andreas is a great programmer, but the example he posted had a bug in
> it and the proposed fix was incorrect.
> 

The patch is correct in its Squeak context.

A feature taken for granted by many programmers as indicated by existing 
code base was working in 99.9%, but was not guaranteed 100%.

If this feature seems natural and its implementation does not break 
anything, why not change the API and make it conform to common expectations?

Andreas either added a new contract, or repaired a broken contract.

Your concerns are about
- portability to other dialect
- compatibility with future parallel thread

The first might not be major, other Smalltalk can be patched too (if 
needed).

The second cause is noble, but maybe not wise, you are putting too much 
constraints on code for an eventual event that might not happen any time 
soon. How can you foresee an API that still isn't defined? And if you 
can, can we?
A french would call that "tirer des plans sur la comète".


> I'll continue this discussion after I've released a stable,
> multi-threaded VM in which Andreas's example breaks.
> 
> Gulik.
> 

With different API contracts and constraints a lot of code would break.

Either, there will be a major rewrite of libraries, or you will have to 
provide a backward compatibility for elder API.

What matters is that code is bad today, because programmer expectations 
do not meet Kernel implementation. And Andreas solved this nicely I think.

Maybe we are all wrong because you are able to provide a clever 
concurrent parallel multithread implementation 99% compatible with 
existing code base, even core BlockContext and Process class, maybe you 
are a few years ahead, but until this is proven, we'll assume Andreas is 
right.

Sorry, I don't like crying with the wolves, but your repeated assertions 
deserved a response.

Friendly.

Nicolas