300Megs with Eclipse. With the base install you mean.

We do hit triple that over here... SOA/JEE and some CLM plugins involved.

Ah RAM is cheap. The problem is that all programs think they need it all
these days.
Philippe Back




GOUBIER Thierry <[email protected]> a écrit :


WzYou are a very directive kind of person, when it comes to thoses things...

If a user want it classified his way, who am I to change his ordering ?

No, the solution isn't yet another level of ill-defined "pattern matching"
to try to get that result. Smalltalk has, from the beginning, been able to
show good practice by letting it's developpers set well though-out
conventions themselves, and by giving them the freedom to do so (maybe not
consciously in some cases, but still). Regressing on that isn't good. Well,
I personnaly will rebuilt yet another RPackage like system to get what I
need, obviously.

By the way, have you noticed that on some systems, Pharo 2.0 starts to feel
slow to use ?

Thierry
________________________________________
De : [email protected] [
[email protected]] de la part de Camillo Bruni [
[email protected]]
Date d'envoi : dimanche 9 septembre 2012 13:25
À : [email protected]
Objet : Re: [Pharo-project] RE :  NewClassOrganizer

On 2012-09-09, at 13:18, GOUBIER Thierry <[email protected]> wrote:

>
> ________________________________________
> De : [email protected] [
[email protected]] de la part de Camillo Bruni [
[email protected]]
> Date d'envoi : dimanche 9 septembre 2012 12:48
> À : [email protected]
> Objet : Re: [Pharo-project] NewClassOrganizer
>
>> Ordering of protocols should happen in the Browser not in the model.
>
> Hum, it looks like to save a few lines there, it's gonna cost a few
thousands lines and caching complexity in the Browser.

I doubt that you'll need any caching there, for any given protocol finding
the proper methods should be O(1), so the only thing that's left is ordering
the protocol.

- define a global ordered collection of predefined categories which will be
  sorted first
- sort the rest alphabetically...

so that's an O(n) lookup overhead for the all the entries. given that there
is hardly any class defining 100 protocols you can redo that calculation
as often as you want...

>> Protocols are simple dictionary entries, the old implementation simply
>> did not want to use dicts for performance / space reasons.
>
>> I doubt that we will add explicit ordering to protocols...
>
> Then the new implementation looks worse than the previous one, from a GUI
point of view in addition to the performance / space ones.

not at all... the old categories are a big mess without any documentation
=> nobody will every maintain that

and as mentioned above, the only trade-off is space, which honestly
you cannot complain about unless we hit something like a 300MB boundary
like Eclipse...

Reply via email to