Slot class builder: Anonymous class modification
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?
On 22 November 2013 16:04, Camille Teruel <camille.teruel@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. -- Best regards, Igor Stasenko.
On 22 November 2013 16:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:04, Camille Teruel <camille.teruel@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.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 22 nov. 2013, at 16:27, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:04, Camille Teruel <camille.teruel@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.
The first is handled by the class builder, the second by the class installer
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.
+1
imo, a better term to use for it would be 'private class' , because anonymous is a bit fuzzy.
+ 1
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:04, Camille Teruel <camille.teruel@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.
-- best, Eliot
2013/11/23 Eliot Miranda <eliot.miranda@gmail.com>
On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:
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.
+1 Anonymous = without name. There's not much to add to it. Regards,
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/11/23 Eliot Miranda <eliot.miranda@gmail.com>
On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua@gmail.com>
wrote:
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.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class. If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
Regards,
-- Best regards, Igor Stasenko.
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature. E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface. ej myObject.schedule(new Runnable {...}); Regards,
On 24 November 2013 01:20, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature.
I am not after changing names here (for naming sake), but more for labeling things properly conceptually. Because "anonymous" carries little or no implications regarding tools or environment, while "private" makes things much more clear. This is why i think it is less fuzzy.
E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
-- Best regards, Igor Stasenko.
On 24 November 2013 00:35, Igor Stasenko <siguctua@gmail.com> wrote:
On 24 November 2013 01:20, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature.
I am not after changing names here (for naming sake), but more for labeling things properly conceptually. Because "anonymous" carries little or no implications regarding tools or environment, while "private" makes things much more clear. This is why i think it is less fuzzy.
Well, surely private classes can have names? "Anonymous" might imply "private", but you could well hand that class around, making it "private in the sense that you need to be given a reference to it". Anonymity and privacy are separate concerns. frank
E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
-- Best regards, Igor Stasenko.
Indeed. Same for listeners etc. Anonymous class has indeed a very clear meaning to me and to any student that has been exposed to Java (which means "a huge lot"). Phil On Sun, Nov 24, 2013 at 1:20 AM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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 onyl> > within another class as occurs in SmalltalkAgents or Newspeak.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature. E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
So I'm confused. what does it means in Java? What is the meaning (I know that anonymous are the one with $ in the name when looking at them from the Java bycode point of view) but beside that?
Indeed. Same for listeners etc.
Anonymous class has indeed a very clear meaning to me and to any student that has been exposed to Java (which means "a huge lot").
Phil
On Sun, Nov 24, 2013 at 1:20 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote: 2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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 onyl> > within another class as occurs in SmalltalkAgents or Newspeak.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature. E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
In Java, Anonymous classes are classes that literally have no explicit name. They are used as replacement for closures. closure = new Closure() { public void do(Object object) { ... } } closure.do(42); A side effect of this construct is that the class is only visible from within the method in which it is defined. So, "anonymous" as a term describes only one facet of the concept. Cheers, Doru On Sun, Nov 24, 2013 at 10:24 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
So I'm confused.
what does it means in Java? What is the meaning (I know that anonymous are the one with $ in the name when looking at them from the Java bycode point of view) but beside that?
Indeed. Same for listeners etc.
Anonymous class has indeed a very clear meaning to me and to any student that has been exposed to Java (which means "a huge lot").
Phil
On Sun, Nov 24, 2013 at 1:20 AM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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 onyl> > within another class as occurs in SmalltalkAgents or Newspeak.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature. E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
-- www.tudorgirba.com "Every thing has its own flow"
Like this: interface Selector { boolean end() ; Object current() ; void next() ; } class Sequence { private Object[ ] seq ; private int next =0 ; public Sequence(int size) { seq=new Object[size] ; } public void add(Object o) { if (next<seq.length) { seq[next] = o ; next++ ; } } public Selector getSelector( ) { return new Selector( ) { private int index=0 ; public boolean end() { return index==next ; } public Object current() { return seq[index] ; } public void next() { index++ ; } } ; } } class TestSequence { public static void main(String[ ] arg) { Sequence sRef=new Sequence(10) ; for (int i=0 ;i<5 ;i++) sRef.add((âstring numero â+i)) ; Selector select=sRef.getSelector() ; while( !select.end()) { System.out.println((String) (select.current())) ; select.next() ; } } } Or this button.addActionListener( new ActionListener() { public void actionPerformed(ActionEvent e) { System.out.println(e.getSource()) ; } } } } On Sun, Nov 24, 2013 at 12:11 PM, Tudor Girba <tudor@tudorgirba.com> wrote:
In Java, Anonymous classes are classes that literally have no explicit name. They are used as replacement for closures.
closure = new Closure() { public void do(Object object) { ... } } closure.do(42);
A side effect of this construct is that the class is only visible from within the method in which it is defined. So, "anonymous" as a term describes only one facet of the concept.
Cheers, Doru
On Sun, Nov 24, 2013 at 10:24 AM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
So I'm confused.
what does it means in Java? What is the meaning (I know that anonymous are the one with $ in the name when looking at them from the Java bycode point of view) but beside that?
Indeed. Same for listeners etc.
Anonymous class has indeed a very clear meaning to me and to any student that has been exposed to Java (which means "a huge lot").
Phil
On Sun, Nov 24, 2013 at 1:20 AM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/11/23 Igor Stasenko <siguctua@gmail.com>:
On 23 November 2013 21:26, Esteban A. Maringolo <emaringolo@gmail.com>
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 onyl> > within another class as occurs in SmalltalkAgents or Newspeak.
+1
Anonymous = without name. There's not much to add to it.
That's the point. Now what is practical implications of it? Think, how far you can go with anonymous versus private class.
If you deny anonymous classes from being private, then you'll immediately hit many problems with tools, which working with public classes and expecting them to have a name. And i don't have to go deep to point on problems: just imagine that you did a change to such 'anonymous' class, now since it is public, all tools is notified about this change, including change logger.. and my question, what you going to log into .changes file in such case?
I can see your point. But then just say that "Anonymous classes are private". Just don't change the name. Anonymous classes are a well know concept used through piles of literature. E.g. In Java the compiler creates anonymous classes everytime you directly instantiate an Interface.
ej myObject.schedule(new Runnable {...});
Regards,
-- www.tudorgirba.com
"Every thing has its own flow"
On 23 November 2013 18:01, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Nov 22, 2013 at 7:27 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:25, Igor Stasenko <siguctua@gmail.com> wrote:
On 22 November 2013 16:04, Camille Teruel <camille.teruel@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.
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).
Hi Camille, What is an anonymous class for you? because it could refer to a lightweight class or a metaclass... Cheers, Hernán El 22/11/2013 12:04, Camille Teruel escribió:
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?
.
On 23 nov. 2013, at 20:58, Hernán Morales Durand <hernan.morales@gmail.com> wrote:
Hi Camille,
What is an anonymous class for you? because it could refer to a lightweight class or a metaclass...
A class that is not installed in the system dictionary, typically generated. As pointed by Igor, that's not a very good name since such a class does have a name, it's just not accessible by simply using that name in code, you need to have a reference to it. However, as pointed by Eliot, that's the name used for two decades now. So in the end, metaclasses are more anonymous than anonymous classes :D
Cheers,
Hernán
El 22/11/2013 12:04, Camille Teruel escribió:
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?
.
participants (9)
-
Camille Teruel -
Eliot Miranda -
Esteban A. Maringolo -
Frank Shearar -
Hernán Morales Durand -
Igor Stasenko -
phil＠highoctane.be -
Stéphane Ducasse -
Tudor Girba