Re: [Pharo-project] About on:
Lukas, The changes I propose would be almost trivial for them to adopt, and might actually make their lives easier in targeting Dolphin, should they wish to do so. The current semantics are <candidMode>watered-down to the point of being pointless, all in the name of being backwardly compatible with something that was questionable even before the existence of tools for exceptions and handling of same</candidMode>. All arguments in favor of preserving current behavior have been based on backward compatibility - nothing on merits. It will be interesting to see what happens when it comes time to de-cruft morphic - *that* will break external code. I will grant you one thing though: if I were to choose between breaking old morphic code or Seaside, I would certainly keep Seaside going, though I suspect the Seaside developers would accomodate us in trying to align the dialects. All they would need to do is use a selector to match the semantics they have learned to accept. It is the first disk pack I would burn - well, maybe just after underscore assignment has been scorched down to the sub-atomic level :) I will probably end up taking some of my own advice. Once my code can move to Pharo[*], I will probably load it into a throw-away image, using the RB therein to rename selectors. The first step would be to get #next and #next: "out of the way," by naming them #nextOrNil and #nextAvailable: - that's what they do. Load my code, and then rename #next to #nextOne and #next: to #nextMany:. These methods would signal EndOfStreamError (new name) to steer clear of default actions. Filing out and loading the resulting code should allow me to safely avoid the (to me deprecated) #next and #next:. It is a shame though, as they are the natural selectors one would want to use. Some slips detection based on packages and/or developer name would help me catch myself should I revert. It is precisely the risk of using the simpler/misleading selectors that has me convinced the breaking change is needed. Failing that, I need to at least solve it for my own code, and I will of course make that available to all. [*] I assume that I will write Dolphin code to export something that Pharo can load. If any of you know of a good solution to that problem, please let me know. In case you are wondering why the renaming is all done in Pharo, it is because it hopefully does a better job of leaving formatting in tact - D5's version of the RB is fairly hostile in that regard. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
renggli@gmail.com 6/5/2008 11:10:07 AM >>> ANSI is a standard and there are cases where it is wrong (commitee decisions = compromise)
I agree, however changing the behavior of #next means that we will not be able to develop Seaside on Pharo. Seaside takes great advantage that Squeak is ANSI compatible. Lukas
On Jun 5, 2008, at 3:27 PM, Bill Schwab wrote:
Lukas,
I have blind copied someone who can comment, or not at his
discretion,
on Cincom's view on this; he never said he was commenting off the record, but I try to err toward assuming that. I got the distinct sense that they are contemplating a change of some type and are also struggling with backward compatibility.
You are correct about ANSI; I was shocked to see what they did. Without reservation, I assert the standard is wrong. Exception handling was created to allow the widespread elimination of precisely the condition that arises when #next reads off the end of a stream. I can always (and probably will if we do not fix this) deprecate #next and #next: in my own work, but that still leaves inconsistencies between and within dialects.
Bill
Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254
Email: bschwab@anest.ufl.edu Tel: (352) 846-1285 FAX: (352) 392-7029
renggli@gmail.com 6/5/2008 7:18 AM >>>
Yes, but it is not consistent, and they are apparently not
happy
with it.
Why? Can you give any pointers?
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.
As far as I see this is inconsistent with the ANSI standard.
Cheers, Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli http://www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The changes I propose would be almost trivial for them to adopt, and might actually make their lives easier in targeting Dolphin, should they wish to do so.
Yes, I agree. The rewrite engine can fix all these things.
All arguments in favor of preserving current behavior have been based on backward compatibility - nothing on merits.
I am only saying that keeping things backward compatible in critical position makes everything easier. Frankly, I like the solution I proposed and that apparently other people have thought out as well. You can use both semantics, depending on what makes more sense in your context. And best of all, it does not break existing code. I am missing a reason why Alan Knight think this solution is not good.
or Seaside, I would certainly keep Seaside going, though I suspect the Seaside developers would accomodate us in trying to align the dialects.
We never forced anybody to align their dialect. If possible, we always changed our own code. We introduced compatibility layers that porters can fill or we simply built our own classes. I hope that we do not have to implement our own stream hierarchy as well.
[*] I assume that I will write Dolphin code to export something that Pharo can load. If any of you know of a good solution to that problem, please let me know. In case you are wondering why the renaming is all done in Pharo, it is because it hopefully does a better job of leaving formatting in tact - D5's version of the RB is fairly hostile in that regard.
The rewrite engine in Squeak/Pharo reformats all code it touches. VisualWorks has some improvements in that area. I discussed with John Brant and he said that these improvements are part of the open-source refactoring browser, however the problem is that Cincom modified the code and that the original improvements are not part of the download on John's website. Therefor it is not clear, what code is clean and what code is commercial. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch
participants (2)
-
Bill Schwab -
Lukas Renggli