Hello Marcus,

Thanks for responding with thorough details, but I'm not such a good OO programmer, so what I need to know is;
Will we be able to continue developing with Pharo using the same old Smalltalk-like syntax? Or, will there be major changes some time in the future? Like how (I think) "_" from Squeak was replaced with ":=" in Pharo!

Thank you.

On Wednesday, February 02, 2022 10:50 CET, Marcus Denker <marcus.denker@inria.fr> wrote:
 


> On 2 Feb 2022, at 09:04, contactme@kathe.in wrote:
>
> I have attached 2 cropped screen-captures of the same class displayed in the class browser;
> class-smalltalk.png is the regular class syntax,
> class-fluid.png is the same class but with the "Fluid" checkbox selected, and shows a different syntax.
>

This is no different syntax, as there is no Syntax (in the sense of Grammar) to define classes.

These are all message sends, just like before.

> May I know what that is all about?
>
> There's a different terminology too, something called "slot", which I have faint memories of being quite like that in "Self" environments.
>

The Fluid class definition has two goals:

1) be extensible.

With the ST80 way, any new parameter would mean adding *a lot* of methods. And every new parameter needs all the other variations,
it���s a serious combinatorial explosion.

Just an example: CompiledMethods and CompiledBlock use CompiledMethodLayout.

But they are created with:

CompiledCode variableByteSubclass: #CompiledMethod
instanceVariableNames: ''
classVariableNames: ''
package: 'Kernel-Methods'

So the system checks for the name and uses the CompiledMethodLayout instead of ByteLayout.
This is hacked in to the system really with ���if the name is CompiledMethod, do not use ByteLayout but CompiledMethodLayout.���

But now

CompiledCode classLayout ==> "a CompiledMethodLayout���

Which means yes, we have a class that we can not define!

With the new class definition, this is explicit:

CompiledCode << #CompiledBlock
layout: CompiledMethodLayout;
slots: {};
tag: 'Methods';
package: ���Kernel'

Now of course we could have added ~20 methods (not sure if that is enough���) of a compiledMethodSubclass:, and
added a version with the layout as a parameter (another 20+1 variants).

But what if we want to add yet another parameter? What is *you* want to do that?

With Fluid, class defintions are extensible, and we can easily extend them.

2) Why are variables not a list of names in a String anymore?

Because we have ���First Class Variables���: every variable in the system has a meta-object, which is implemented
by a class.

Point instanceVariables first "#x => InstanceVariableSlot���

So yes, there is an Object that represents ���the variable #x in Point���. With an api. The compiler delegates
code generation to it fore read and write. You can think of it as a Meta Object Protocol for Variables...

(I sometimes wonder if the name Slot was good, we could just think of it as ���InstanceVariable��� in the sense of
the Variable being modelled as an object, instead of a String).

This is a big topic, but the idea is: let���s use Objects, not Strings!

We can define our own kind of Variable (see the hierarchy of Variable), and the use of the array {} now allows us to
actually define a class that uses this special kind of Variable.

There is a presentation I did about it last year:

https://vimeo.com/603398445


Marcus