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

[Juan Vuletich]

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
researchgate.net/profile/Juan-Vuletich
independent.academia.edu/JuanVuletich
patents.justia.com/inventor/juan-manuel-vuletich
linkedin.com/in/juan-vuletich-75611b3
twitter.com/JuanVuletich

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20240209/8652c661/attachment.htm>