Re: [Pharo-project] [Pharo-users] Where do I find KeyedSet?
Hi Stef 2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules: 1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea) doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy" it sounds feasible for you? what do you think? Hernán
Previous names is a good idea We should adopt it! Stef On Jan 15, 2011, at 9:52 AM, Hernán Morales Durand wrote:
Hi Stef
2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules:
1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea)
doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy"
it sounds feasible for you? what do you think?
Hernán
On Jan 15, 2011, at 9:52 AM, Hernán Morales Durand wrote:
Hi Stef
2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules:
1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea)
doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy"
yes this would be nice to have tool doing it for us.
it sounds feasible for you? what do you think?
Hernán
On Sat, 15 Jan 2011, Hernán Morales Durand wrote:
Hi Stef
2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
Note that KeyedSet has nothing to do with PluggableSet. PluggableSet is a set where you can specify the hash and equality of two objects with blocks. This gives you great flexibility without creating a subclass of Set. KeyedSet is like a dictionary, but the keys of the objects are not stored in the data structure, because the objects know it themselves. This means that the data structure will have a smaller memory footprint. Levente
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules:
1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea)
doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy"
it sounds feasible for you? what do you think?
Hernán
Hi, and thanks for the clarification Levente, This points me to a question, since it seems KeyedSet was removed because at that time no users were found. Is that the criteria (i.e. no users) for removing a class from the Core image? Assuming you have NO resources for checking use of classes by the users, and core developers have NO care/time/energy for annotating their changes (or there is no tool to do it or nobody uses it), I have this idea: You continue deleting classes as if nothing happens, BUT let users to vote for a request an addition or NOT removal. Then you win on two aspects: -First you get a free log of what has been removed -When votes reach a consensus value, that you may seriously consider including whatever is in question. How about tagging issues like [RFI] (Request for Inclusion) ? And every comment counts like a vote. Opinions? Hernán 2011/1/15 Levente Uzonyi <leves@elte.hu>:
On Sat, 15 Jan 2011, Hernán Morales Durand wrote:
Hi Stef
2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
Note that KeyedSet has nothing to do with PluggableSet. PluggableSet is a set where you can specify the hash and equality of two objects with blocks. This gives you great flexibility without creating a subclass of Set. KeyedSet is like a dictionary, but the keys of the objects are not stored in the data structure, because the objects know it themselves. This means that the data structure will have a smaller memory footprint.
Levente
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules:
1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea)
doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy"
it sounds feasible for you? what do you think?
Hernán
I do not know. What would like is - well documented packages classes with tests and that we can load what we need. - small core Stef On Jan 17, 2011, at 7:03 PM, Hernán Morales Durand wrote:
Hi, and thanks for the clarification Levente,
This points me to a question, since it seems KeyedSet was removed because at that time no users were found. Is that the criteria (i.e. no users) for removing a class from the Core image?
Assuming you have NO resources for checking use of classes by the users, and core developers have NO care/time/energy for annotating their changes (or there is no tool to do it or nobody uses it), I have this idea:
You continue deleting classes as if nothing happens, BUT let users to vote for a request an addition or NOT removal. Then you win on two aspects:
-First you get a free log of what has been removed -When votes reach a consensus value, that you may seriously consider including whatever is in question.
How about tagging issues like [RFI] (Request for Inclusion) ? And every comment counts like a vote.
Opinions?
Hernán
2011/1/15 Levente Uzonyi <leves@elte.hu>:
On Sat, 15 Jan 2011, Hernán Morales Durand wrote:
Hi Stef
2011/1/15 Stéphane Ducasse <stephane.ducasse@inria.fr>:
On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
Try PluggableSet
Note that KeyedSet has nothing to do with PluggableSet. PluggableSet is a set where you can specify the hash and equality of two objects with blocks. This gives you great flexibility without creating a subclass of Set. KeyedSet is like a dictionary, but the keys of the objects are not stored in the data structure, because the objects know it themselves. This means that the data structure will have a smaller memory footprint.
Levente
http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.htm...
Is there a way for you guys to deprecate deleted classes or mantain a record of deleted behaviors? (IIRC VW did this from 2.x versions)
We try but we do not have the engineers of VW. Now find somebody that pay us just 3 engineers full time for two years and you will not recognized pharo and its process.
I know we are very few, but what about this idea, instead of just deleting a class we may adopt these simple rules:
1 - If deleting a class add the deleted class name somewhere (in a method?) 2 - If renaming a class, make the class to know its previous names like #previousNames (Norberto Manzanos implemented this for his own package management and I think is a great idea)
doesn't require tools, just some consensus and maybe a modified #deleteClass to enforce this "policy"
it sounds feasible for you? what do you think?
Hernán
participants (3)
-
Hernán Morales Durand -
Levente Uzonyi -
Stéphane Ducasse