> On 21 Nov 2020, at 10:14, Noury Bouraqadi <bouraq...@gmail.com> wrote:
>
> Indeed, posting these emails is useful. It helps keeping us posted about the
> ongoing progress of Pharo.
>
> I like they are grouped by topic, so it makes easier to get what it's about.
> Sean's suggestion would indeed understand more. Though I expect it will
> require more time/effort to write. Moreover, these emails are already long.
> I'm affraid they'll become way too long.
>
> A solution that mixes both might be posting more often updates. But, again I
> expect it to be time consuming.
>
Yes, writing for real takes effort…
E.g. last week I did a trivial PR after I got annoyed about seeing too many
ivars tat are not used and did a first step (mostly a skipped test):
Cleanup-Unused-Ivars #7780
https://github.com/pharo-project/pharo/pull/7780
But then I realised that the core of the test:
variables := Smalltalk globals allBehaviors flatCollect: [ :each | each
instanceVariables ].
variables := variables reject: [ :each | each isReferenced ].
variables := variables collect: [ :each | each definingClass ] as: Set.
actually is more interesting then being just a trivial test for a trivial
cleanup… In the end it is trivial, but it is as an example for why
things like turning variables into objects is interesting:
=======
As you might be aware, we added to Pharo the concept of “Firsts class
Variables” that is, there is a meta object for every variable in the system.
Historically, even though you might think that “everything is an Object” in
Smalltalk, the memory constraints that existed when ST80 was created did not
make reifying everything possible. Even today, this has to be done with care:
for example, instances of TempVariable are only created on demand in Pharo.
As for ST80: Instance Variables are one example of things that are not Objects:
The only thing that we have are the names (that is, strings) of the instance
variables defined by a class. The order is fixed so that the offset of the
variables in the list of all instance variable of the class hierarchy actually
is the offset that the bytecode uses to access this variable.
Thus all code dealing with Variables tend to be formulated quite “low level”.
It exposes a lot of implementation details: you need to find names, then the
offset, then use a low level bytecode scanning method to check if a method
accesses this offset.
So how do “First Class” Variables improve the situation? Let’s see what we have
to do to find all classes that define an instance variable that is not accessed.
Read more:
https://blog.marcusdenker.de/finding-unused-variables-an-example-for-first-class-variables
