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