Yes, Transcript will be too slow.

Actually, I didn't look carefully at the Deprecation class.
It has show/raise warning options and a simple way to collect deprecations with #deprecationsWhile:
Maybe I should run production code with

� � � � Deprecation raiseWarning: false.

�This is of course a global setting.

Your idea with the window sounds cool but how/when are you going to show it ? And what about headless ?

On 30 Sep 2012, at 01:24, Igor Stasenko <siguctua@gmail.com> wrote:

> On 29 September 2012 23:12, Sven Van Caekenberghe <sven@stfx.eu> wrote:
>> Guys,
>>
>> So yesterday I deployed a new server based on an #20309 image, with a single Metacello config for my code, and a separate manual load for Seaside 3.1 (which I use as an interface to work with the headless image) - and all went well !
>>
>> But I had to apply one manual hack: remove the deprecation from #includesSubString: (for Seaside).
>>
>> I feel like we need another, more silent kind of deprecation for situations like this. Library/framework/application writers targetting multiple Pharo versions are being hit way too hard by this, for - in this case certainly -, no good reason. Creating two versions (I introduced a special package Pharo-Forward-Compatibility just for this), is not worth it (unless you absolutely want the best Pharo 2.x code like I do).
>>
>> I would imagine something similar to Deprecation which maybe prints on the Transcript, but is otherwise silent, except when some switch is turned on.
>>
>
> Putting transcript is possible only for non-performance critical methods.
> Put it in wrong place, and it will crawl like slug ..
> So, we need a kind-of non-interfering deprecation.
>
> I am all for having less intrusive deprecation system.
> IMO, to fix deprecation (if developer really cares), one needs only
> the method which sends the deprecated message, bringing a full
> Debugger is overkill in 99% of cases.
>
> What can we do is to make a nice wrapping around this, so if running
> code hits deprecated method,
> it should bring a special popup window titled 'deprecated methods
> used' or something,
> and if user will click on the button there, he can see the list of
> methods which having send sites which hit deprecated methods, i.e. a
> list populated from pairs:
>
> MyClass>>foo using deprecated �SystemClass>>deprecatedBar
>
> clicking on that entry will open a browser in #foo method, where you can fix it.
>
> (sure thing, if method #foo runs millions of times, it should not
> produce millions of very same entries
> in that list. we only interested in unique sender->receiver pairs.
> And run-time check for that is far less expensive comparing printing
> that stuff on transcript every time).
>
> To speed things up even more, we can even just do this on a first hit,
> and then recompile deprecated method to not do any checks but perform
> only what they exist for. But this will require some dark magic,
> either with compiler, or using method wrappers of some sort.
>
> At the end, what we have is a system simply runs as usual, except from
> small window, which (if users care to click on) will bring the list of
> deprecations hit so far.
>
>> It would give us the power to deprecate much more things even 'silly renames'. And less external stuff would break.
>>
>> What do you think ?
>>
>> Sven
>>
>> --
>> Sven Van Caekenberghe
>> http://stfx.eu
>> Smalltalk is the Red Pill
>>
>
> --
> Best regards,
> Igor Stasenko.
>