Re: [Pharo-users] Where do I find KeyedSet?

>
> On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
>
>> Try PluggableSet
>>
>> http://www.mail-archive.com/pharo-project@.../msg22890.html
>>
>> 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.

> Hi Stef
>
> 2011/1/15 Stéphane Ducasse <[hidden email]>:
>>
>> On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
>>
>>> Try PluggableSet
>>>
>>> http://www.mail-archive.com/pharo-project@.../msg22890.html
>>>
>>> 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 Stef
>
> 2011/1/15 Stéphane Ducasse <[hidden email]>:
>>
>> On Jan 14, 2011, at 6:24 PM, Hernán Morales Durand wrote:
>>
>>> Try PluggableSet
>>>
>>> http://www.mail-archive.com/pharo-project@.../msg22890.html
>>>
>>> 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"

> On Sat, 15 Jan 2011, Hernán Morales Durand wrote:
>
>> Hi Stef
>>
>> 2011/1/15 Stéphane Ducasse <[hidden email]>:
>>>
>>> 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@.../msg22890.html
>>>>
>>>> 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 <[hidden email]>:
>> On Sat, 15 Jan 2011, Hernán Morales Durand wrote:
>>
>>> Hi Stef
>>>
>>> 2011/1/15 Stéphane Ducasse <[hidden email]>:
>>>>
>>>> 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@.../msg22890.html
>>>>>
>>>>> 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
>>>
>>
>