Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write:
<intellectual response> Many system classes contain lots of methods that are confusing, duplicates of similar functionality, bogus, old, unused, untested and undocumented . This makes the system more complex, especially for newcomers, but also for everyone else trying to make changes. This is often technical debt, cleanup that has been postponed. It is important that knowledgeable developers try to clean up by simplifying things. If not, the situation will never improve. Of course we have to be careful, in this particular case I was. We have done many hundreds of these removals in the past years, with very little problems. We have also done way more dangerous things, like change signatures and semantics of existing methods. In my opinion we can safely go ahead and remove this. A couple of others concurred. If someone wants to go through the trouble to do this with deprecation and a rewrite rule, fine. <emotional response> Sure, the responses "Trying to be *somewhat* compatible and verifying (even quickly) that it's not breaking a gazillion things is the very least someone can do... Backward compatibility is NOT a sin! ;):" and "Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide." are pure technical, intellectual arguments and not passive-aggressive criticism. Right.
On 22 Feb 2019, at 19:54, Benoit St-Jean via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
From: Benoit St-Jean <bstjean@yahoo.com> Subject: Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write: Date: 22 February 2019 at 19:54:55 GMT+1 To: Pharo Development List <pharo-dev@lists.pharo.org>
Trying to be *somewhat* compatible and verifying (even quickly) that it's not breaking a gazillion things is the very least someone can do... Backward compatibility is NOT a sin! ;)
On 2019-02-22 13:45, Sven Van Caekenberghe wrote:
On 22 Feb 2019, at 19:39, Stephan Eggermont <stephan@stack.nl> wrote:
Sven Van Caekenberghe <sven@stfx.eu> wrote: .
So I propose to remove [Stream|Collection]>>#write:
What say thou ? Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide.
Stephan You forgot GitHub and all private company repositories in the world.
-- ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
I think that with the automatic rewrite support and the Migrator packages we can get the best of the world: moving and improving while helping people to migrate.
From that perspective: - test suite - automatic rewrite are a super good insurance for moving applications.
Now I would really like to see how we can improve the automatic migration. And yes we should really clean the system. We started with the API of String in the past and this was funny to see all the cruft that accumulated over years. Stef
On 22 Feb 2019, at 22:55, Sven Van Caekenberghe <sven@stfx.eu> wrote:
<intellectual response>
Many system classes contain lots of methods that are confusing, duplicates of similar functionality, bogus, old, unused, untested and undocumented . This makes the system more complex, especially for newcomers, but also for everyone else trying to make changes. This is often technical debt, cleanup that has been postponed.
It is important that knowledgeable developers try to clean up by simplifying things. If not, the situation will never improve.
Of course we have to be careful, in this particular case I was. We have done many hundreds of these removals in the past years, with very little problems. We have also done way more dangerous things, like change signatures and semantics of existing methods.
In my opinion we can safely go ahead and remove this. A couple of others concurred.
If someone wants to go through the trouble to do this with deprecation and a rewrite rule, fine.
<emotional response>
Sure, the responses
"Trying to be *somewhat* compatible and verifying (even quickly) that it's not breaking a gazillion things is the very least someone can do... Backward compatibility is NOT a sin! ;):"
and
"Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide."
are pure technical, intellectual arguments and not passive-aggressive criticism. Right.
On 22 Feb 2019, at 19:54, Benoit St-Jean via Pharo-dev <pharo-dev@lists.pharo.org> wrote:
From: Benoit St-Jean <bstjean@yahoo.com> Subject: Re: [Pharo-dev] Proposal to remove [Stream|Collection]>>#write: Date: 22 February 2019 at 19:54:55 GMT+1 To: Pharo Development List <pharo-dev@lists.pharo.org>
Trying to be *somewhat* compatible and verifying (even quickly) that it's not breaking a gazillion things is the very least someone can do... Backward compatibility is NOT a sin! ;)
On 2019-02-22 13:45, Sven Van Caekenberghe wrote:
On 22 Feb 2019, at 19:39, Stephan Eggermont <stephan@stack.nl> wrote:
Sven Van Caekenberghe <sven@stfx.eu> wrote: .
So I propose to remove [Stream|Collection]>>#write:
What say thou ? Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide.
Stephan You forgot GitHub and all private company repositories in the world.
-- ----------------- Benoît St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)
Sven Van Caekenberghe <sven@stfx.eu> wrote:
<intellectual response>
"Check the selectors used in the latest packages on squeaksource, ss3, smalltalkhub and decide."
are pure technical, intellectual arguments and not passive-aggressive criticism. Right.
Yes, it is a very, very serious response. A few years ago I did some prototypes with DeprecationFinder and MonticelloProjects, applying it to a subsection of smalltalkhub. This is essential infrastructure. Both for deprecations and to recover dependencies. Should be easy to get a paper out of it. Stephan
participants (3)
-
ducasse -
Stephan Eggermont -
Sven Van Caekenberghe