[Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections

[Jon Raiford]

Hi Juan,

Thank you for your thoughtful reply.  I don’t disagree with anything you said and I very much appreciate hearing your philosophy on changes.

I just want to clarify one thing. I didn’t mean to suggest a high maintenance effort regarding the code versions. Ideally any concept of tracking compatibility would be somewhat automatic (the code was last developed on version x, etc) with the option of potentially tagging it later when an incompatibility is found. But even that wasn’t fully thought out.  Regardless, my intention was to share a somewhat outsider’s opinion about dangers of breaking changes and it was not to push for a specific solution.

Jon

From: Cuis-dev <cuis-dev-bounces at lists.cuis.st> on behalf of Juan Vuletich via Cuis-dev <cuis-dev at lists.cuis.st>
Date: Friday, February 9, 2024 at 1:43 PM
To: Discussion of Cuis Smalltalk <cuis-dev at lists.cuis.st>
Cc: Juan Vuletich <juan at cuis.st>, Jon Raiford <raiford at labware.com>
Subject: Re: [Cuis-dev] [DEFECT] #copyFrom:count: for OrderedCollections
Hi Jon,

It's nice to see you here. Welcome!

On 2/9/2024 12:55 PM, Jon Raiford via Cuis-dev wrote:
Hi,

My obligatory “long time listener, first time caller”:  I joined the list about a year ago and have enjoyed reading the daily happenings even though I haven’t really contributed directly yet. I was offline recently and finally got a chance to catch up. Wow! There were more messages in the last couple weeks than I’ve seen on this list since I joined (combined, or at least it felt like that).

Anyway, I wanted badly to be upset with Juan’s change to OrderedCollection class>>new:. Generally speaking, I do think that peer/sibling classes should be allowed to implement the same method with very different behavior. Of course if the parent class also implements the method then it does seem reasonable that there are restrictions, and I do think that defining those rules is also reasonable. No I’m not going to suggest what those rules are 😊

The bigger issue seems to be with the concept of changing well established historical behavior. I assume we are all familiar with Python’s switch from v2 to v3. We know now that Python survived the version change and is very much thriving, but back when the change happened it wasn’t so sure that it would. Breaking changes are bad, especially when there is a lot of code out there that potentially will no longer work.

Of course. The tension between moving forward and not wanting to break things is something every software system struggles with.

On a Smalltalk system, where for any existing method there may be some external code potentially depending on it, the problem is harder. Strict, 100% percent back compatibility for every method means that almost no changes are possible. Only fixes for bad bugs and additions of new APIs are possible. We don't want that for Cuis. Cuis was started to enable evolution.



I think that was Gerald’s point about marking it as deprecated for a time and having the method log the soon to be invalid usage. It may be worth going a bit further than that and having a standard way to tag source code to say what version it was written in, or what versions it is compatible with. Then, if breaking changes are documented by version then you have a proactive way to look for code patterns that need to change. It may even be possible to make a tool to help with this. In this particular case, “OrderedCollection new:” should be easy enough to find.

Just my 2 cents as a bit of an outsider’s opinion.

Jon

The approach we have been following with Cuis since it started is something like this:

- Any change that is seen as an improvement can be done. Back compatibility is not guaranteed.

- The possible consequences of each change are evaluated in an informal, intuitive way. This is augmented with 1.Running tests. 2.Reviewing code that could be affected. This can be done only if there are tests to run, and for client code that has been published. We can't do this with 3rd parties private code.

- If it seems (yeah, this is fuzzy) that the change is risky, we don't hurry. We reach out to people that could be affected. We ask the community (via email) to review the changes, do their own evaluation of risks and give their opinion. This is not done often, but it is done sometimes.

- In general, most changes are seen as "low risk" and we move ahead. Some changes are riskier, but the risk is seen as worth taking. Any affected code in the Cuis base image and all packages in repos in the Cuis-Smalltalk organization are updated. This may take a bit of time. Developers using Cuis for their projects may need to adapt their code.

- All this is not perfect, or even well defined. We always try to improve.

This approach has allowed Cuis to go through deep redesign of central parts of the system, including Strings, Characters, Floats, FileSystem and the whole Morphic system. A lot of code has broke, and was later updated. No one was left behind.

However, there are reasons to believe this will be less and less of a problem in the future. Cuis is becoming more stable. After disruptive past changes like migration to Spur, TrueType and VectorGraphics and Unicode, the main objectives set for Cuis when it was started are finally a reality. I expect most interesting activity to happen in external packages and applications, not so much on the base image itself.

A recent initiative to alleviate these issues is the Stable Releases of Cuis. This means that projects concerned about compatibility can stay in the same Stable Release until they are ready to face change in the base system.

Still, something like what you envision could be possible. In any case, I would not track the compatibility of all code over time. I think this would only make sense for a small set of classes and methods. For instance, many methods in kernel classes are intended to be used only by the kernel classes themselves, and are then "free to change". But we don't have the distinction between "public" and "private" in Smalltalk. So, how do we define this set?

Other questions that come to mind. Who would be willing to spend a significant amount of effort in writing the specifications that should be honored over time? Should they be a document (like ANSI Smalltalk), a set of TestCases, some kind of MethodAnnotations? How long would it take until people say all this is only worth doing if compatibility between dialects is also considered, and this is not just for Cuis?

Thanks,


--

Juan Vuletich

cuis.st

github.com/jvuletich<http://github.com/jvuletich>

researchgate.net/profile/Juan-Vuletich<http://researchgate.net/profile/Juan-Vuletich>

independent.academia.edu/JuanVuletich<http://independent.academia.edu/JuanVuletich>

patents.justia.com/inventor/juan-manuel-vuletich<http://patents.justia.com/inventor/juan-manuel-vuletich>

linkedin.com/in/juan-vuletich-75611b3<http://linkedin.com/in/juan-vuletich-75611b3>

twitter.com/JuanVuletich<http://twitter.com/JuanVuletich>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240209/3ccbfaf9/attachment-0001.htm>