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