[Pharo-dev] Slot class builder: Anonymous class modification

Eliot Miranda eliot.miranda at gmail.com
Sat Nov 23 12:01:26 EST 2013

On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua at gmail.com> wrote:

> On 22 November 2013 16:25, Igor Stasenko <siguctua at gmail.com> wrote:
>> On 22 November 2013 16:04, Camille Teruel <camille.teruel at gmail.com>wrote:
>>> Hi everyone,
>>> With Esteban, we bumped into a problem with anonymous subclasses and the
>>> slot class builder.
>>> The problem is that once an anonymous class is created is not possible
>>> to modify it.
>>> Here is the problem:
>>> For creating an anonymous class with the new class builder API you do
>>> something like:
>>> myAnonymousClass := AnonymousClassInstaller make: [ :classBuilder |
>>>         classBuilder
>>>                 superclass: Object;
>>>                 name: #MyAnonymousClass;
>>>                 .... ]
>>> What happens is that the class builder asks the class installer if the
>>> class named #MyAnonymousClass exists or not to know if this a class to be
>>> created or to be modified.
>>> Here, the strategy of the anonymous class installer is to always answer
>>> no. So ok, now you have you're anonymous class.
>>> But what happens when you do something like:
>>> myAnonymousClass addInstVarNamed: #newIV
>>> Since the class has no clue of what class installer was used to create
>>> it, it instantiate a new one, and a PharoClassInstaller !
>>> This new class installer then says to the class builder that there is no
>>> class named MyAnonymousClass so it creates it! And it install it in the
>>> system dictionary!
>>> And myAnonymousClass is not modified.
>>> So there is several problem here:
>>> - a class doesn't know which class installer was used to create it
>>> - even if the class would know that, the anonymous class installer would
>>> always say that it doesn't know it and a new class would be created
>>> So one possible solution for that is to have one class installer per
>>> environment (so add one iv in SystemDictionary right now), like that a
>>> class would know what class installer was used to create it.
>>> What would happen then is that you don't create anonymous classes
>>> anymore, that is to say a class not installed in any environment, but
>>> instead you create a class that exist in an environment separated from the
>>> system dictionary.
>>> What do you think?
>>> i think that this expression:
>> myAnonymousClass addInstVarNamed: #newIV
>> should create and answer new original class.
>> And don't take me wrong a 'new class' means just a new class object,
>> which is not installed/registered anywhere, because it is done at next step
>> (if its necessary).
>> I'm not sure what this 'class installer' thingy comes from and it looks
>> completely irrelevant. We must have clear separation between operations
>> which creating new classes
>> and installing/registering them inside environment.
>> Because anonymous class is not one which has no name, it is one which is
>> not registered in any public place. For the rest , it should behave in same
>> way as public one.
>> The fact that IDE tries to hide it and simulate as if you modified
>> existing class is not really important here, because it is higher-level
>> contracts and responsibilities.
> imo, a better term to use for it would be 'private class' , because
> anonymous is a bit fuzzy.

I disagree.  Anonymous classes is the term that has been used for over two
decades.  It means, literally, a class that has no name because it is not
in Smalltalk (or in a top-level environment if the dialect has namespaces).
 This is not at all fuzzy.  Private class means something quite different,
a class that is private to some environment, e.g. a class nested within
another class as occurs in SmalltalkAgents or Newspeak.

>> --
>> Best regards,
>> Igor Stasenko.
> --
> Best regards,
> Igor Stasenko.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20131123/df44d4ca/attachment-0002.html>

More information about the Pharo-dev mailing list