> On 2 Feb 2022, at 09:04, contac...@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
