String>>includesSub[S|s]tring: - do we need another kind of deprecation ?

> 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.
>

> 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
>

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

> 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.
>
> 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
>
>
>
>

> On Sun, Sep 30, 2012 at 10:15 AM, Sven Van Caekenberghe <[hidden email]>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.
>>
>>    
>
> I was going to suggest you that. It is also accesible from the Settings UI.
> BTW, maybe we should do this in #cleanUpForProduction?
>  

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

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