On 23 November 2013 18:01, Eliot Miranda <[email protected]> wrote:
> > > > On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <[email protected]> wrote: > >> >> >> >> On 22 November 2013 16:25, Igor Stasenko <[email protected]> wrote: >> >>> >>> >>> >>> On 22 November 2013 16:04, Camille Teruel <[email protected]>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. > > Don't you see, that once you saying that anonymous class is one which not installed in environment, you turning it into private to that environment, isn't? Because at the end private means 'not accessible' publicly, and this is exactly what we have. Nested classes is a bit different is just extra scoping, which not necessary makes things private, it just adds a level of indirection but you still can access it via environment through the chain of parent scope(s).
