On 30 September 2012 10:15, Sven Van Caekenberghe <[email protected]> wrote: > 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 ? > You show it if it not already open, and if you hit deprecated method. In headless mode, warnings is simply written to debug log/console. (but for speed reasons, we should also write them only once per deprecation, i think).
> 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. >> > > -- Best regards, Igor Stasenko.
