Damien,
I guess that would work but here are my concerns:
First peekFor: is not really deprecated. It's only being marked deprecated so that we can take it back and change its function.
Second, if deprecated notification is an option then it's easily ignored.
How about we do this? There has been a lot of argument about Squeak being stuck in the mud because we need to keep stability instead of favoring cleaning up the code. Some have argued that we need to burn the disk packs to allow us to move forward. How about a middle ground? With proper organization we could develop an upgrade doc and possibly upgrade tools. It would be much easier to do this now then trying to figure it all out later. I like the idea of adding: <functionalChangeInVersion: 3.10> or: <deprecatedInVersion: 3.10> so we can build tools later. (Pragma allNamed: #functionalChangeVersion: in: MyClass)
IF the change is well documented in a highly visible upgrade document, that has a permanent location, and we do our best to point people to that document from many different places, and it is very easy for people (or the release team) to add to the document all deprecated methods and their replacements, or changes in function, THEN I'd say we just change it (including changing all senders), document it, advertise it and move on.
What do you think?
Ron
From: Damien Cassou Sent: Wednesday, February 28, 2007 3:36 PM
In Squeak there was at least a way to indicate a deprecated method. I saw it. There was a preference to activate notifications of deprecations. This possibility should still exist. Maybe we can:
- implement a #peekIf: method with the same source code as current
#peekFor:
- depreciate #peekFor: method and call #peekIf: from there to keep
compatibility
- wait one or two releases
- change #peekFor: to only peek and conform to standard.
What do you think ?
-- Damien Cassou