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.
