Smalltalk › Pharo › Pharo Smalltalk Developers

Tricky Metaclass>>binding

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Denis Kudriashov

Tricky Metaclass>>binding

I found interesting trick in system: the way how class side perform #binding message:

Metaclass>>binding

"return an association that can be used as the binding

To share it between methods, reuse an existing one if possible"

^self methodDict

ifEmpty: [nil -> self]

ifNotEmpty: [:dict | dict anyOne classBinding]

It leads to interesting behaviour of class without class side methods:

NewClass class binding == NewClass class binding "==> false"

Generally I discovered in the logic which decode class of method in last literal. Interesting that for instance side methods it is always represented by GlobalVariable. And for class side methods it is always general Association.

Can we make this behaviour more consistent? And will it improve the system? (I thing about possible complications to bootstrap).

As solution I would introduce new kind of LiteralVariable: ClassBinding with two subclasses InstanceSideBinding and ClassSideBinding. They will take place in last method literal.

InstanceSideBinding will be used in Smalltalk dictionary for classes instead of GlobalVariable.

And it will keep variable with class side binding. So the trick will be not needed anymore.

So what do you think?

Marcus Denker-4

Re: Tricky Metaclass>>binding

On 12 Sep 2017, at 11:32, Denis Kudriashov <[hidden email]> wrote:

I found interesting trick in system: the way how class side perform #binding message:

Metaclass>>binding
"return an association that can be used as the binding
To share it between methods, reuse an existing one if possible"
^self methodDict
ifEmpty: [nil -> self]
ifNotEmpty: [:dict | dict anyOne classBinding]

It leads to interesting behaviour of class without class side methods:

NewClass class binding == NewClass class binding "==> false"

Generally I discovered in the logic which decode class of method in last literal. Interesting that for instance side methods it is always represented by GlobalVariable. And for class side methods it is always general Association.

Can we make this behaviour more consistent? And will it improve the system? (I thing about possible complications to bootstrap).

As solution I would introduce new kind of LiteralVariable: ClassBinding with two subclasses InstanceSideBinding and ClassSideBinding. They will take place in last method literal.
InstanceSideBinding will be used in Smalltalk dictionary for classes instead of GlobalVariable.
And it will keep variable with class side binding. So the trick will be not needed anymore.

So what do you think?

It would be nice to improve it.. I like the idea of a ClassBinding subclass (this way it is distinct from Global Vars, too). The only question of adding one ivar to ca. 5000 Objects

is not too much.. do we get enough out of it for that amount of memory?

Maybe there is some other possibility?

Marcus

Guillermo Polito

Re: Tricky Metaclass>>binding

I don't know... I found the idea of having a Metaclass binding strange...

I mean,

- metaclasses are not stored in any name dictionary such as Smalltalk

- nobody references them directly in source code but by their direct classes

The metaclass binding is there just for one thing really: methods need an association to know their class in case they have to do a super send. And transitively this is a compiler problem also. But anybody else accesses metaclasses' bindings.

Stephane Ducasse-3

Re: Tricky Metaclass>>binding

At the minimum having classBinding instead of GlobalBinding would be
already a good step.
Then since the metaclass and the class are a real couple could we not
have an object shared by both (but it would cost one indirection).

On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito
<[hidden email]> wrote:

> I don't know... I found the idea of having a Metaclass binding strange...
>
> I mean,
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
>
> The metaclass binding is there just for one thing really: methods need an
> association to know their class in case they have to do a super send. And
> transitively this is a compiler problem also. But anybody else accesses
> metaclasses' bindings.

Denis Kudriashov

Re: Tricky Metaclass>>binding

Yes.

In fact I just want avoid usage of general Association in that places.

So the question do we need two classes for instance and class side bindings? Or single ClassBinding is enough? In that case class side binding will have nil as a key (which would be the same for possible ClassSideBinding)

2017-09-13 9:43 GMT+02:00 Stephane Ducasse <[hidden email]>:

At the minimum having classBinding instead of GlobalBinding would be
already a good step.
Then since the metaclass and the class are a real couple could we not
have an object shared by both (but it would cost one indirection).

On Tue, Sep 12, 2017 at 5:33 PM, Guillermo Polito
<[hidden email]> wrote:
> I don't know... I found the idea of having a Metaclass binding strange...
>
> I mean,
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
>
> The metaclass binding is there just for one thing really: methods need an
> association to know their class in case they have to do a super send. And
> transitively this is a compiler problem also. But anybody else accesses
> metaclasses' bindings.

Marcus Denker-4

Re: Tricky Metaclass>>binding

In reply to this post by Guillermo Polito

> On 12 Sep 2017, at 17:33, Guillermo Polito <[hidden email]> wrote:
>
> I don't know... I found the idea of having a Metaclass binding strange...
>
> I mean,
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
>
> The metaclass binding is there just for one thing really: methods need an association to know their class in case they have to do a super send. And transitively this is a compiler problem also. But anybody else accesses metaclasses' bindings.
>

yes, we need it just for the last literal.

We added the “if there is a method, get the binding from there” we adde as else
we would compiler every class side method with a new Association instance, which
wastes lots of space.

Marcus

Denis Kudriashov

Re: Tricky Metaclass>>binding

So after discussion the solution would be:

- ClassBinding for instance side method literals and globals dictionary (instead of GlobalVariable)

- MetaclassBinding for the last literal of class side methods. It will include proper comment about where it is used and how, with description of current trick

2017-09-13 16:45 GMT+02:00 Marcus Denker <[hidden email]>:

> On 12 Sep 2017, at 17:33, Guillermo Polito <[hidden email]> wrote:
>
> I don't know... I found the idea of having a Metaclass binding strange...
>
> I mean,
> - metaclasses are not stored in any name dictionary such as Smalltalk
> - nobody references them directly in source code but by their direct classes
>
> The metaclass binding is there just for one thing really: methods need an association to know their class in case they have to do a super send. And transitively this is a compiler problem also. But anybody else accesses metaclasses' bindings.
>

yes, we need it just for the last literal.

We added the “if there is a method, get the binding from there” we adde as else
we would compiler every class side method with a new Association instance, which
wastes lots of space.

Marcus

Stephane Ducasse-3

Re: Tricky Metaclass>>binding

I imagine that you imply keeping the cGlobalVariable binding for the
real global variable.

On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov <[hidden email]> wrote:

> So after discussion the solution would be:
> - ClassBinding for instance side method literals and globals dictionary
> (instead of GlobalVariable)
> - MetaclassBinding for the last literal of class side methods. It will
> include proper comment about where it is used and how, with description of
> current trick
>
> 2017-09-13 16:45 GMT+02:00 Marcus Denker <[hidden email]>:
>>
>>
>> > On 12 Sep 2017, at 17:33, Guillermo Polito <[hidden email]>
>> > wrote:
>> >
>> > I don't know... I found the idea of having a Metaclass binding
>> > strange...
>> >
>> > I mean,
>> > - metaclasses are not stored in any name dictionary such as Smalltalk
>> > - nobody references them directly in source code but by their direct
>> > classes
>> >
>> > The metaclass binding is there just for one thing really: methods need
>> > an association to know their class in case they have to do a super send. And
>> > transitively this is a compiler problem also. But anybody else accesses
>> > metaclasses' bindings.
>> >
>> yes, we need it just for the last literal.
>>
>> We added the “if there is a method, get the binding from there” we adde as
>> else
>> we would compiler every class side method with a new Association instance,
>> which
>> wastes lots of space.
>>
>> Marcus
>
>

Denis Kudriashov

Re: Tricky Metaclass>>binding

Yes

13 сент. 2017 г. 18:59 пользователь "Stephane Ducasse" <[hidden email]> написал:

I imagine that you imply keeping the cGlobalVariable binding for the
real global variable.

On Wed, Sep 13, 2017 at 4:52 PM, Denis Kudriashov <[hidden email]> wrote:
> So after discussion the solution would be:
> - ClassBinding for instance side method literals and globals dictionary
> (instead of GlobalVariable)
> - MetaclassBinding for the last literal of class side methods. It will
> include proper comment about where it is used and how, with description of
> current trick
>
> 2017-09-13 16:45 GMT+02:00 Marcus Denker <[hidden email]>:
>>
>>
>> > On 12 Sep 2017, at 17:33, Guillermo Polito <[hidden email]>
>> > wrote:
>> >
>> > I don't know... I found the idea of having a Metaclass binding
>> > strange...
>> >
>> > I mean,
>> > - metaclasses are not stored in any name dictionary such as Smalltalk
>> > - nobody references them directly in source code but by their direct
>> > classes
>> >
>> > The metaclass binding is there just for one thing really: methods need
>> > an association to know their class in case they have to do a super send. And
>> > transitively this is a compiler problem also. But anybody else accesses
>> > metaclasses' bindings.
>> >
>> yes, we need it just for the last literal.
>>
>> We added the “if there is a method, get the binding from there” we adde as
>> else
>> we would compiler every class side method with a new Association instance,
>> which
>> wastes lots of space.
>>
>> Marcus
>
>