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 <[email protected]> wrote:
> On 29 September 2012 23:12, Sven Van Caekenberghe <[email protected]> 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.
>
