Damien, It cannot be "fixed" without breaking said external code. However, there is a very clear way for those interested to refactor old code to be consistent. The only alternative is to use selectors such as #nextOne, #nextMany:, etc., to do the jobs that #next and #next: purport to do. I can do that myself; my hope is to fix the real problem, and to gradually bring VW along with us.
Perhaps my problem is that I fell into a Smalltalk (Dolphin) that had this right (and grumbled about it, only to later be convinced of its correctness), and now find the analogy to #at: very clear as a result. IMHO, this is a situation where we should lead, but you already knew that. Time for me to start my commute. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: [EMAIL PROTECTED] Tel: (352) 846-1285 FAX: (352) 392-7029 >>> [EMAIL PROTECTED] 06/05/08 7:39 AM >>> On Thu, Jun 5, 2008 at 1:06 PM, Bill Schwab <[EMAIL PROTECTED]> wrote: > Yes, but it is not consistent, and they are apparently not happy with it. > Object Arts' solution is consistent both with itself and with yoga of > structured exception handling. However, at this point, it appears that you > do not want to make the change, so I will stop pressing. I personally would like to see this change in Pharo. However, there is no consensus and it might affect a lot of external code that the refactoring can't change. -- Damien Cassou Peter von der Ahé: «I'm beginning to see why Gilad wished us good luck». (http://blogs.sun.com/ahe/entry/override_snafu) _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
