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