Updates for Pharo 10

[JanBliznicenko]

Multiple fixes and updates for Pharo 10, incl. usage of Spec2 instead of Spec1.

Partially fixes https://github.com/magritte-metamodel/magritte/issues/294

• [x] MAMorphicDropList>>#buildMorphView uses DropListModel from Spec1
• [x] MAMorphicDate>>#buildMorphView uses DateModelfrom Spec1
• [x] TokenCollectorMorph>>#textInput uses TextInputFieldModel from Spec1

Makes Magritte compatible with Pharo 10+, but incompatible with Pharo 8-. Might be advisable to create separate branch for Pharo 10+ or Pharo8-

[seandenigris]

We’ve been using platform packages. The latest should be implemented as cleanly as possible with shims for older supported platforms. Branches IMHO are a no-go because we’re out of the Smalltalk world and into Unix/git h*ll

[JanBliznicenko]

Ok, I will attempt to do that. Since I have known git before Smalltalk, for me, handling all these packages for specific deprecated versions of Pharo in a single branch/baseline I consider hell :)

So, I have not much experience with using these ST implementation / Pharo version specific packages - how to do that properly, please? I should create "Magritte-Pharo10-Morph" with the updates implemented as extensions of the original package? Or should it be a copy of the original package with change applied only to it? Or should I do the opposite - create "Magritte-Pharo9-Morph" with the original preserved code and have the default name as the current one for Pharo10+?

[seandenigris]

Ah. Maybe I can learn something. I fear that once there are multiple branches, changes will have to be propagated all over the place necessitating manual conflict resolution. Unwarranted?

[JanBliznicenko]

Well, I am no expert in neither, but AFAIK it depends, both worlds seem to have advantages and disadvantages and we are each used to something different and the bad stuff from the other is what we consider hell :). You always end up with having to deal with applying same fix multiple times, either in different branches or in different packages (like you could have 3 packages, each for different version of Pharo, and you need to apply fix in all 3).

The git branches way is usually used when you are ok with maintaining primarily the most-recent-pharo one, and doing just critical bug fixes for older Pharo versions, because cherry-picking or merging many branches is time consuming. If you want to keep fully updating Magritte even for Pharo 6 and similar, the Smalltalk way might be better (you have to copy the change only if it touches any part different between these version, in that case it is way harder to do it in Smalltalk way).

Anyway, when I did have Pharo-version-specific packages, I ended up with the original main package for the latest Pharo and some backward-compatibility-one for the older versions. That means having Magritte-Morph for Pharo 10+ and something like Magritte-Morph-Pharo9 for Pharo9-. Do you want to have it like that in Magritte or vice versa - having the original package unchanged and create something like Magrite-Morph-Pharo10 for Pharo10+. Furthermore, I have no idea how to handle compatibility with GemStone etc., I know nothing about their supported features, how does Morphic and Spec look there etc.

[seandenigris]

If you want to keep fully updating Magritte even for Pharo 6 and similar, the Smalltalk way might be better (you have to copy the change only if it touches any part different between these version, in that case it is way harder to do it in Smalltalk way).

This is precisely what I was thinking, although I only started doing it this way because I saw other projects doing that.

Well, I am no expert in neither, but AFAIK it depends, both worlds seem to have advantages and disadvantages and we are each used to something different and the bad stuff from the other is what we consider hell :).

You have brought an interesting perspective that I'd like to think through more fully, so I posted on Pharo Dev

You always end up with having to deal with applying same fix multiple times, either in different branches or in different packages (like you could have 3 packages, each for different version of Pharo, and you need to apply fix in all 3).

Agreed, but I feel that the duplication is less with the platform packages due to your next point below, but I've never actually tested that so maybe it's just confirmation bias!

Anyway, when I did have Pharo-version-specific packages, I ended up with the original main package for the latest Pharo and some backward-compatibility-one for the older versions. That means having Magritte-Morph for Pharo 10+ and something like Magritte-Morph-Pharo9 for Pharo9-.

Yes, that is my current policy.

Furthermore, I have no idea how to handle compatibility with GemStone etc., I know nothing about their supported features, how does Morphic and Spec look there etc.

Don't worry about platforms you don't code on. I try not to intentionally break other platforms, but it's up to those community members to decide whether to support Magritte.

[seandenigris]

I'm going to merge this. If someone speaks up about Morphic in P<9, we'll deal with it then.