+1 Stef
On Aug 25, 2010, at 12:53 PM, Schwab,Wilhelm K wrote: > While I'm on rant, what happened to the good old day when men were men and > 2+'2' was not 4? I *still* have bugs in my R data frame code because of that > nonsense - just tell me I blew it, please?? Ceorsing integers to floats to > make things like 2+Float pi is a good thing, converting strings to numbers is > coddling that ultimately backfires. > > Bill > > > > > ________________________________________ > From: pharo-project-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K > [bsch...@anest.ufl.edu] > Sent: Wednesday, August 25, 2010 5:01 AM > To: Pharo-project@lists.gforge.inria.fr > Subject: Re: [Pharo-project] String to Number conversion > > Squeak has a long tradition of silent failures of all types (in the image and > the vm), and IMNSHO, it is a **really** bad idea with terrible consequences > and needs to be fixed. Default actions that return nil merely push problems > down stream to a point where there is no context to figure out what went > wrong. I think much of this goes back to the late 70's and early 80's, > before structured exception handling, and has never been modernized. > Dolphin, which started life in the mid 90's, is built from the ground up to > do these things correctly. Once one learns that the exceptions are indeed > helping to make things work reliably, it is hard to imagine making something > robust without them. > > Exceptions can be expensive, both to set up handlers, and even more so when > exceptions are thrown. You have identified the answer, which is to provide > #readFrom:ifFail: (or #readFrom:onError: - whatever you want to call it) > that evaluates a block when things go wrong, which allows one to bypass the > overhead, much like #at:ifAbsent:; if error and remedy are near by, it is > easy to do and skips the overhead. For the lazy<g>, or simply for frameworks > that can/should use exceptions to handle exceptional conditions (big > separation between the problem and anything that knows how to cope with it), > #readFrom: (without the block) does the robust/correct thing, and raises an > exception. As you no doubt know, it can (often should) be written in terms > of #readFrom:ifFail: with the block raising the exception. > > Things will break for a while, but I hesitate to think how much stuff is just > plain broken and we never notice it because things answer nil and/or ignore > error conditions. The industry tried to formalize such > head-in-the-sand-hope-it-goes-away design under the fancy name "defensive > programming." It remains a useful approach when used sparingly to keep > critical systems running, but it generally failed under its own lack of > merit. It was popularized as a way to cope with the dreaded UAEs of 16 bit > Windows, which was in turn due to the lack of exception handling and ensured > execution in the GUI, which lead to incomplete cleanup, memory leaks, and all > kinds of crashes. > > YES. PLEASE DO THIS. **GREAT** IDEA. You might take a look at > > > http://www.squeaksource.com/PharoInbox/DolphinCompatibility-Streams-BillSchwab.1.mcz > > for what I consider to be very much related changes to stream I/O. Since it > quickly became obvious to me that #next and #next: were not going to change > any time soon, I simply stopped using them myself; instead I write code using > #nextOne, #nextMany:, and #nextAvailable:. You will also find methods such > as #nextDWORD to help with binary file formats, device interfacing, etc . > > It is a work in progress, but the idea is to have read streams bark when they > run out of data, unless (#nextAvailable:) specifically authorized to > truncate. I also have some text converters modeled after Dolphin's > framework. I don't think I have released those yet, but plan to do so > eventually. Because of the problem you have identified, I have added some > tests (and throw exceptions when they fail) for whether the stream is or is > not at the end or read an expected number of types, etc. > > Thanks for working on this! > > Bill > > > > ________________________________________ > From: pharo-project-boun...@lists.gforge.inria.fr > [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Guillermo Polito > [guillermopol...@gmail.com] > Sent: Tuesday, August 24, 2010 4:33 PM > To: Pharo-project@lists.gforge.inria.fr > Subject: [Pharo-project] String to Number conversion > > http://code.google.com/p/pharo/issues/detail?id=2857 > > Which will be the impact in the system and other tools to throw an error when > the conversion cannot take place? > I think an error must be thrown, but should it be in Pharo 1.2 or in next > version? > > On Tue, Aug 24, 2010 at 11:45 AM, Nicolas Cellier > <nicolas.cellier.aka.n...@gmail.com<mailto:nicolas.cellier.aka.n...@gmail.com>> > wrote: > In squeak, (Integer readFromString: 'foo') ->Error > > Use: > - Integer readFrom: 'foo' ifFail: [0], tp get backward compatibility, > - (Integer readFrom: 'foo' ifFail: []), to get nil > > Though it is possible, I dislike anwsering nil, because it would mean > a bunch of #readFrom: send should be protected by #ifNil: Blocks... > 1) That's nonsense, readFrom:ifFail: already does the work. > 2) you cripple the code with Error conditions and end up with > unreadable C-looking like code > (3 lines of Error condition crap for 1 line of underlying algorithm > at every function call) > 3) Exception handling can avoid long chains of ifFail: / ifNil: tests > > But that conversation already took place many times... > > I'd like the readFrom:ifFail: form to be generalized to other objects, > with default behaviour raising an Error. What do you think ? > > Nicolas > > 2010/8/24 Johan Brichau <jo...@inceptive.be<mailto:jo...@inceptive.be>>: >> >> On 24 Aug 2010, at 15:19, Stéphane Ducasse wrote: >> >>> I thought that readFromString: was raising an error and that guessNumber* >>> was returning zero >> >> I thought that too. I even have application code that shows that this used >> to return nil in some version of Pharo... >> But: >> >> 'foo' asInteger = nil >> Integer readFromString: 'foo' = 0 >> 'foo' asNumber -> Error >> >> aargh :-( >> >> disclaimer: currently testing this in pharo1.1 >> >> Johan >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project@lists.gforge.inria.fr<mailto: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<mailto: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 _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
