--- Begin Message ---
It is a very interesting effort.
The following:
Superclass < #MyObject
uses: #MyTrait;
slots: { #a. #b };
classVariables: { #A. #B };
tags: #(Core) ;
package: #MyPackage
Seems more complex to implement than:
Superclass < (#MyObject
uses: #MyTrait;
slots: { #a. #b };
classVariables: { #A. #B };
tags: #(Core) ;
package: #MyPackage)
The reason is that in the first class definition, the binary operator has
precedence over keyword messages, which means that it is equivalent to:
(Superclass < #MyObject)
uses: #MyTrait;
slots: { #a. #b };
classVariables: { #A. #B };
tags: #(Core) ;
package: #MyPackage
And as such, the code assume that it modifies the class _after_ its creation,
which could be tricky if one want to have it fast.
But maybe there is something obvious that I did not see...
Cheers,
Alexandre
> On 07-01-2020, at 21:32, ducasse <[email protected]> wrote:
>
> Hello Denis
>
>
>>
>> What is Fluid class parser?
>
> This is the name of the class definition we sketched and presented at
> Maribor.
> The idea is how to fight the combinatory explosion of parameters (tags,
> ephemerons, traits, slots, ….)
> For now I’m putting in place the structure to be able to create a tree of
> definition nodes for a class definition
>
> Superclass < #MyObject
> uses: #MyTrait;
> slots: { #a. #b };
> classVariables: { #A. #B };
> tags: #(Core) ;
> package: #MyPackage
>
> The minimal class definition is the following one:
>
> Superclass < #MyObject
> package: #MyPackage
>
> or
> Superclass < #MyObject
>
> Like that we get closer to ruby and other language that have a compact class
> definition.
> One of the key constraints is that we do not want to break the syntax.
> So everything is message based and consistent with the syntax and our motto.
>
> But we will see.
> I prefer talking with something running.
> When I worked on the package I rewrote everything three times.
>
> The idea is that this class definition parser should replace the
> ClassDefinitionParser (which we will keep for the
> traditional class definition but that in a couple of years from now should
> vanish).
>
> S.
>
>
>
>
>
>> Is it the name of currently integrated parser?
>>
>> вт, 7 янв. 2020 г. в 19:48, ducasse <[email protected]>:
>> Thanks Pablo
>>
>>
>> Last Week
>> - Working on concurrent programming booklet
>> - Enlumineur
>> - Better iceberg explanation with Pablo
>> - Fluid class parser
>>
>> This week
>> - Fluid class parser
>> - Enlumineur
>> - Consortium meeting
>> - PBE80
>> - Working on concurrent programming booklet
>>
>>
>>
>> > Hello, last week was a short one but some things have been done:
>> >
>> > - [VM] Porting the GC fix to Pharo 7 / 8 VM
>> > - [VM] Building for the different Platforms
>> > - [VM] Signing for OSX
>> > - [VM] The versions will be available today to start testing it before
>> > promoting them to stable.
>> > - [Pharo8] Fixing Issues before the release
>> > - [VM Dev] Starting to work in improving tests in JIT and GC.
>> >
>> > --
>> > Pablo Tesone.
>> > [email protected]
>> >
>>
>>
>>
>
--- End Message ---
