Who uses poolDictionaries? New class template cleanup
Hi all, I am preparing slides for a course. I came to the typical: Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers' Which made me think: Who uses poolDictionaries? I suspect extremely few of us. Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol And have the new class template as follows? Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes' It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students. Greetings, ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
+1 On 12 nov. 2013, at 16:39, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
+1 On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
+10 On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Hi, I'd like to draw your attention to something else: consistency. I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it. Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors? Just my 2 cents Joachim Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Yuri, Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy). Joachim Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On 14 Nov 2013, at 11:10, jtuchel@objektfabrik.de wrote:
Yuri,
Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right?
Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life. As for me, the class creation is wrong. We are not creating a method like: Object compile: 'class "Primitive. Answer the object which is the receiver''s class. Essential. See Object documentation whatIsAPrimitive." <primitive: 111> self primitiveFailedâ classified: #'class membership' we just type a method. Iâd like something user friendly for cass like: - select a superclass - give your class a name - add instance variable * name variable * choose variable type - add class variable⦠- add pool dictionary I think that you get the idea
PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy).
Joachim
Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
Yuri, the GUI idea has an up and a down side. The up side is that it's much easier to use. The down side is that there is no way to ex- and import a class definition without a proper syntax. So what is needed is both: a proper syntax and some way to make things easier for the mousey people. Maybe the tools aspect is what Johan initially was talking about: why not make the class creations (let's call it) snippet exchangeable for certain user groups. A setting that says: "include Pool Dictionaries in default class creation template", Right? If so, we should also be able to choose if we want class inst vars (does Pharo support them?) and class variables. Who uses class vars anyways ;-) Joachim Am 14.11.13 11:21, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:10, jtuchel@objektfabrik.de wrote:
Yuri,
Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right? Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life.
As for me, the class creation is wrong. We are not creating a method like: Object compile: 'class "Primitive. Answer the object which is the receiver''s class. Essential. See Object documentation whatIsAPrimitive."
<primitive: 111> self primitiveFailedâ
classified: #'class membership'
we just type a method.
Iâd like something user friendly for cass like: - select a superclass - give your class a name - add instance variable * name variable * choose variable type - add class variable⦠- add pool dictionary
I think that you get the idea
PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy).
Joachim
Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
--
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 14 Nov 2013, at 11:10, jtuchel@objektfabrik.de wrote:
Yuri,
Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right?
Yes it would, the thing is that I had no idea what they do. And other guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life.
Yuriy have a look at Pharo by example. They should be explain. PoolDictionaries (as in Pharo) refers to special classes holding classvariables so that these variables can be statically shared (know at compiled time) between different hierarchies. For example Cr is directly used instead of having to type Text cr everywhere.
As for me, the class creation is wrong. We are not creating a method like: Object compile: 'class "Primitive. Answer the object which is the receiver''s class. Essential. See Object documentation whatIsAPrimitive."
<primitive: 111> self primitiveFailedâ
classified: #'class membership'
we just type a method.
Iâd like something user friendly for cass like: - select a superclass - give your class a name - add instance variable * name variable * choose variable type - add class variable⦠- add pool dictionary
I think that you get the idea
PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy).
Joachim
Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
just for the record, I am no old timer Smalltalker, I come from python just introduced the past year to pharo. I dont pay attention to the poolDictionaries , I have seen it used as concept by NBOpenGL , looks like a fan idea, it does not distract me from my coding, I am glad its there because one day I may need it. So for now I just ignore it and I see no side effect. One thing to make clear here is that its normal not to use or need stuff from a language. As I said I come from python , python comes with enormous standard library with tons of features, If you install cpython which is the most popular python implementation (by far) you install also its standard library. Its unrealistic to expect the average python coder to use more than 10% from that and 10% maybe be even optimistic. The tricky part is that each coder uses a different 10% . There is no such thing as a majority, a majority is a collection of minorities that are in some form of agreement. Each coder has different goals and different ways of coding. But thats is what it makes a language great, when a specific problem arises the language will provide an easy solution however exotic / rare the problem is, it wont reply to you "wait that thing you ask is kinda rare, so I dont care" because you wont care about the language as well. Someone could bring forth the argument that these things should go to third party libraries , but again there is a problem here. How you inform the users about these libraries ? How you guarantee that these libraries will keep being maintaine ?. So its no concidence that python comes with an enormous standard library and there are many coders that code in python and never use any third library and they love python or be precise cpython for that. Java is a similar story too. So I think the question "who uses poolDictionaries " is one those mirage questions that from far make perfect sense but the closer you come to the problem they make less and less sense . Of course about having a message that containes no poolDictionaries as argument, its makes perfect sense. Things should always be as simple as possible, but not more simple. Making a nice gui has little to do with the API itself. You dont want your API to depend on the GUI , you want the GUI to depend on the API. The API should make the life easy, the GUI should make the lifer easier. On Thu, Nov 14, 2013 at 1:14 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
On Nov 14, 2013, at 11:21 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
On 14 Nov 2013, at 11:10, jtuchel@objektfabrik.de wrote:
Yuri,
Okay, so why not go one step further and kill PoolDictionaries? I mean, if no one uses them and you'd like to hide them from the users,
they obviously are unnecessary. That would be a real cleanup, right?
Yes it would, the thing is that I had no idea what they do. And other
guys from my team had no idea. And as far as I know a lot of people are not aware of them. So for me itâs ok to hide PoolDictionaries. Maybe in future they will become obsolete because of the features that Slots can provide. Maybe they will come back to life.
Yuriy have a look at Pharo by example. They should be explain. PoolDictionaries (as in Pharo) refers to special classes holding classvariables so that these variables can be statically shared (know at compiled time) between different hierarchies. For example Cr is directly used instead of having to type Text cr everywhere.
As for me, the class creation is wrong. We are not creating a method like: Object compile: 'class "Primitive. Answer the object which is the receiver''s class. Essential. See Object documentation whatIsAPrimitive."
<primitive: 111> self primitiveFailedâ
classified: #'class membership'
we just type a method.
Iâd like something user friendly for cass like: - select a superclass - give your class a name - add instance variable * name variable * choose variable type - add class variable⦠- add pool dictionary
I think that you get the idea
PoolDictionaries are potentially dangerous, because you can put things
there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy).
Joachim
Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the
class definition template changed drastically. It took me quite a while to get used to that.
And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble. Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
--
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
2013/11/14 jtuchel@objektfabrik.de <jtuchel@objektfabrik.de>
Yuri,
Okay, so why not go one step further and kill PoolDictionaries?
This was done in OOVM / Resilient Smalltalk. And it was clean and worked well.
I mean, if no one uses them and you'd like to hide them from the users, they obviously are unnecessary. That would be a real cleanup, right?
Definitely. lots of pool dictionaries has already been removed from Pharo (some of them were put into class variable, other really removed). But removing this feature is not possible because frameworks as seaside or moose may use them, and most Pharo users program with Pharo because of these frameworks. Hiding it from the user is a good solution to me. It means their usage is disapproved. Therefore new users will not use them. However old school guys and frameworks may use it, they know how to add them. We already have "uses:" for Traits that is a hidden selectorPart by default, and everyone's happy with it.
PoolDictionaries are potentially dangerous, because you can put things there that make Images harder to reproduce if you don't put the code to fill the Dictionaries into some script that will be run in the right situations (places like #loaded in envy).
Joachim
Am 14.11.13 11:05, schrieb Yuriy Tymchuk:
On 14 Nov 2013, at 11:02, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble.
Is anything mentioning PoolDictionaries? I have no idea what it is.
The other thing is that we should go from text for class creation to nice ui, but itâs a long term goal.
And what if I need PoolDictionaries? How hard will it be to find the
place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
Am 14.11.13 10:49, schrieb Martin Dias:
+10
On Tue, Nov 12, 2013 at 9:24 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
+1
On Nov 12, 2013, at 4:39 PM, Johan Fabry <jfabry@dcc.uchile.cl> wrote:
Hi all,
I am preparing slides for a course. I came to the typical:
Number subclass: #Complex instanceVariableNames: 'real imaginary' classVariableNames: '' poolDictionaries: '' category: 'ComplexNumbers'
Which made me think: Who uses poolDictionaries? I suspect extremely few of us.
Why not add this to Class: Class>>subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames category: aSymbol ^self subclass: aSymbol instanceVariableNames: instVarNames classVariableNames: classVarNames poolDictionaries: '' category: aSymbol
And have the new class template as follows?
Object subclass: #NameOfSubclass instanceVariableNames: '' classVariableNames: '' category: 'Kernel-Classes'
It would be a bit cleaner. I know us old timers don't even see the poolDictionaries: line anymore, but I dislike having to explain it to students.
Greetings,
---> Save our in-boxes! http://emailcharter.org <---
Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
--
Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
-- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
2013/11/14 jtuchel@objektfabrik.de <jtuchel@objektfabrik.de>
And what if I need PoolDictionaries?
Unless my understanding of the proposal is way off, you would just add "poolDictionaries: 'whatever'" before "category:". No horrible breaking of anything would happen. Cheers, Sergi
Am 14.11.13 11:23, schrieb Sergi Reyner:
2013/11/14 jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de> <jtuchel@objektfabrik.de <mailto:jtuchel@objektfabrik.de>>
And what if I need PoolDictionaries?
Unless my understanding of the proposal is way off, you would just add "poolDictionaries: 'whatever'" before "category:". No horrible breaking of anything would happen.
Cheers, Sergi I disagree ;-) I find it hard to remember the ordering of these parameters. I sometimes have this problem with classInstVars in VAST.
But you are right in that using a simpler template as the default won't remove the whole feature. Joachim -- ----------------------------------------------------------------------- Objektfabrik Joachim Tuchel mailto:jtuchel@objektfabrik.de Fliederweg 1 http://www.objektfabrik.de D-71640 Ludwigsburg http://joachimtuchel.wordpress.com Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
On Nov 14, 2013, at 7:29 AM, jtuchel@objektfabrik.de wrote:
Unless my understanding of the proposal is way off, you would just add "poolDictionaries: 'whatever'" before "category:". No horrible breaking of anything would happen.
Cheers, Sergi I disagree ;-) I find it hard to remember the ordering of these parameters. I sometimes have this problem with classInstVars in VAST.
But you are right in that using a simpler template as the default won't remove the whole feature.
And if you don't remember the ordering, just browse the implementer of the message in the template, you will find other variants right next to it :-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
Note that I'm not advocating removing PoolDictionaries. Just to have the subclassing template not mention them. I would leave the subclassing message with the poolDictionaries: argument in the system for people to use it if they want to. On Nov 14, 2013, at 7:02 AM, jtuchel@objektfabrik.de wrote:
Hi,
I'd like to draw your attention to something else: consistency.
I remember the days when Cincom added Namespaces to classes and the class definition template changed drastically. It took me quite a while to get used to that. And there is this other aspect in the consistency field: most Smalltalk literature will include and address that line. If you learn Smalltalk, such small differences can cause trouble.
And what if I need PoolDictionaries? How hard will it be to find the place to add my reference to them? A fair amount of Pharo code may not make much use of PoolDictionaries, but other dialects do. I know Pharo has the concept of "never look back" and it is good to be prepared to cut off old strings. But there is a price to it.
Seaside, apart from being a great web framework, has achieved something that was excellent and helped the whole Smalltalk universe make a leap forward: all Smalltalk dialects moved closer together and honestly worked on being more compatible. Suggestions like this may not break much of this per se, but many such cracks make a wide canyon. I find the argument that a certain line of code may irritate students a bit weak. It may make their life harder once they read code from other dialects. Should we remove class browsers because students are used to use text editors?
Just my 2 cents
Joachim
---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD lab - Computer Science Department (DCC) - University of Chile
participants (9)
-
Camille Teruel -
Clément Bera -
Johan Fabry -
jtuchel＠objektfabrik.de -
kilon alios -
Martin Dias -
Sergi Reyner -
Stéphane Ducasse -
Yuriy Tymchuk