[squeak-dev] Re: Compatibility with external packages

Levente Uzonyi leves at elte.hu
Sun Jan 10 19:55:48 UTC 2010


On Sun, 10 Jan 2010, Andreas Raab wrote:

> Levente Uzonyi wrote:
>> There's no guarantee that old code works even if all previously removed 
>> methods are added again. For example if a subclass of Set in an external 
>> package has it's own version of #findElementOrNil: or #fullCheck, it may 
>> have no effect, since it will have no senders in Set. I think that the only 
>> way is to update external packages and use them. So far the only package I 
>> fixed is DynamicBindings, the fixed version is available here:
>> http://squeaksource.com/KomHttpServer/DynamicBindings-ul.12.mcz .
>
> I think we're all in violent agreement here. The introduction of such changes 
> has to be decided in the concrete context. From my point of view, due to the 
> importance of Seaside we have no choice but to provide backwards 
> compatibility for DynamicBindings - the failure mode is too obscure to risk 
> having people run into it.
>

If you're moving your code to a newer image, you can update 
DynamicBindings and everything is fine. I agree that it's easier to not 
update, but we should motivate people to update. A deprecation warning 
would be nice IMO.

>>>  platformName
>>>    "After Squeak version 3.6, #platformName was moved to SmalltalkImage "
>>>     ^ ((Smalltalk classNamed: 'SmalltalkImage')
>>>         ifNil: [^ Smalltalk platformName]) current platformName
>>> 
>> 
>> What about this?
>> SystemDictionary >> orSmalltalkImage
>>
>>     ^(self at: #SmalltalkImage ifAbsent: [ ^self ]) current
>> 
>> Which would let us write: Smalltalk orSmalltalkImage platformName.
>
> Eeek! :-) Juan has the right solution for this problem in Cuis:
>
> SmalltalkImage class>>current
> 	^Smalltalk
>
> and then leave the methods in Smalltalk which is the only sensible place 
> anyway. (I'd really like to move things back at some point)

That looks nice, but how do you ensure that SmalltalkImage exists?

>
>> As I noted above, having these methods in the image do not ensure 100% 
>> backwards compatibility with external packages.
>> Five years may be too much, noone will remember in 2015 that some 
>> methods/classes can be removed from the image.
>> Sometimes it's easier to fix the external packages (like the 
>> DynamicBindings case, where the fix is fully backwards compatible).
>> I think we should produce a migration guide, like the Seaside developers:
>> http://www.seaside.st/documentation/migration . This could also include a 
>> list of deprecated features (methods/classes).
>
> I agree with all of these comments as well (and I think David does, too). The 
> main issue is: Sometimes we need backwards compatibility. DynamicBindings is 
> a situation where I strongly feel it's worth it because it's so widely used 
> in all sorts of old and new Seaside versions.

It's worth to do it, but we should also motivate people to update.

For DynamicBindings, the best would be to take over the DynamicBindings 
repository at squeaksource.com and move the developement there from the 
KomHttpRepository.


Levente

>
> Cheers,
>  - Andreas
>
>



More information about the Squeak-dev mailing list