[Pharo-project] Some Object methods that could be removed ?
Hi Guys, Here are 4 Object methods that could maybe be removed, right ? Object>>#xxxClass no real senders except MethodFinder Object>>#identityHashPrintString 1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either Object>>#mouseUpBalk a does nothing hook, no other implementors only two senders, looks like being related to debugging Object>>#windowReqNewLabel: a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model The last two could be changed to a conditional perform if we want to keep the hooks. If there are no objections, I could produce a slice (or slices). Sven BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-) -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
Go for it!! :) (though I am not a reliable source to represent the users of these methods) On 2012-12-04, at 12:50, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Guys,
Here are 4 Object methods that could maybe be removed, right ?
Object>>#xxxClass
no real senders except MethodFinder
Object>>#identityHashPrintString
1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either
Object>>#mouseUpBalk
a does nothing hook, no other implementors only two senders, looks like being related to debugging
Object>>#windowReqNewLabel:
a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model
The last two could be changed to a conditional perform if we want to keep the hooks.
If there are no objections, I could produce a slice (or slices).
Sven
BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-)
I think this was my hack to not show the "all" category :P so technically it is not faster :P but I tricked you in believing so..
On Dec 4, 2012, at 5:00 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Guys,
Here are 4 Object methods that could maybe be removed, right ?
Object>>#xxxClass
no real senders except MethodFinder
this is not needed anymore as #class now is always send (no special byte code).
Object>>#identityHashPrintString
1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either
remove
Object>>#mouseUpBalk
a does nothing hook, no other implementors only two senders, looks like being related to debugging
yes, should be removed.
Object>>#windowReqNewLabel:
a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model
yes.
The last two could be changed to a conditional perform if we want to keep the hooks.
If in doubt, just remove :-)
If there are no objections, I could produce a slice (or slices).
yes!
Sven
BTW, What did Nautilus eat recently ? Browsing Object now opens immediatlely ;-)
-- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On the same topic. Do we have a VM that marks methods as they are executed? We should really do a cleaning session by running an image for a week or so and remove all methods that are unused!
On 04.12.2012 17:54, Camillo Bruni wrote:
On the same topic.
Do we have a VM that marks methods as they are executed?
We should really do a cleaning session by running an image for a week or so and remove all methods that are unused!
That's an ... overly optimistic view :) http://www.youtube.com/watch?feature=player_detailpage&v=yxqkzSbKhF8#t=270s If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week. I'd imaging the influx of #doesNotUnderstand issues in the tracker would be quite impressive though :P Cheers, Henry
On 05 Dec 2012, at 11:05, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week.
Of course, just because there are no users doesn't mean that a method should be removed. But there is just too much cruft on Object, SequenceableCollection, String, Integer, .. that does not belong there. At least many of these less general methods should be packages as extensions. I am also sure that by 'using the image for a week', Camillo also meant running all tests, as well as building and running tests for major Pharo clients (@Stephan). Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill
On 2012-12-05, at 07:47, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 05 Dec 2012, at 11:05, Henrik Sperre Johansen <henrik.s.johansen@veloxit.no> wrote:
If the same holds true for the % of objects that are methods, you would probably remove around 90% depending on usage pattern during that particular week.
Of course, just because there are no users doesn't mean that a method should be removed. But there is just too much cruft on Object, SequenceableCollection, String, Integer, .. that does not belong there. At least many of these less general methods should be packages as extensions.
I am also sure that by 'using the image for a week', Camillo also meant running all tests, as well as building and running tests for major Pharo clients (@Stephan).
yes of course :) my use-case would include something like - install a couple of huge configurations (here we should include all software that is important to us) - open all UI elements - run all tests and then removing the methods should not happen blindly, but reviewed.
On 04 Dec 2012, at 17:48, Marcus Denker <marcus.denker@inria.fr> wrote:
On Dec 4, 2012, at 5:00 PM, Sven Van Caekenberghe <sven@stfx.eu> wrote:
Hi Guys,
Here are 4 Object methods that could maybe be removed, right ?
Object>>#xxxClass
no real senders except MethodFinder
this is not needed anymore as #class now is always send (no special byte code).
Object>>#identityHashPrintString
1 senders except MethodFinder can easily be moved to caller, not generally useful we have no #hashPrintString either
remove
Object>>#mouseUpBalk
a does nothing hook, no other implementors only two senders, looks like being related to debugging
yes, should be removed.
Object>>#windowReqNewLabel:
a hook that returns true, no other implementors only one sender (SystemWindow>>#relabel), looks like seeing any object as model
yes.
The last two could be changed to a conditional perform if we want to keep the hooks. If in doubt, just remove :-)
If there are no objections, I could produce a slice (or slices).
yes!
participants (4)
-
Camillo Bruni -
Henrik Sperre Johansen -
Marcus Denker -
Sven Van Caekenberghe