2014-02-27 8:39 GMT+01:00 Pharo4Stef <[email protected]>: > > On 26 Feb 2014, at 23:08, Nicolas Cellier < > [email protected]> wrote: > > That's exactly for this kind of reasons that I developped an > ExtendedNumberParser connected to Number class>>readFrom:, to allow a > variety of formats used in the rest of the world. > > It would have been easy to allow upper letter exponents in this parser, > but the class was considered superfluous and removed from Pharo 3.0... > > > Nicolas > > to explain a bit the removal of that class. I do not think that Java has > three different parser for number in its core or ruby? > From a maintenance perspective this is a lot of stress on us (not only at > the code level the conceptually). > If we do not have a guy like you taking care of such issues in Pharo daily > how can we continue maintaining different parser? > This is why we should simplifiy. > Why this is the not the job of a GemstoneToPharoPharo to do that? Or > ExternalNumberParser (to me it if conceptually different than > ExtendedNumberParser) and it should be packaged somewhere else. We got at > least two ASTs, three parsers and this cannot be. > > Stef > > > Yes, I understand the motivation for simplification, but...
For me, providing a way to parse very simple objects like numbers dates etc... from a string representation SHOULD be a core service. And, indeed, IT IS the #readFrom: API. For dates, there is a well known exhange format, so that's what we can use. For numbers, less so, but most other languages either share sufficient coverage of literal syntax, or provide common libraries for such parsing (like scanf etc...) If you provide a limited API (limited to Smalltalk literal syntax, Squeak/Pharo dialect), then it's sufficiently different from the rest of the world to require extension from app. developpers POV. So you put the burden on application developpers which will re-program the same micro-package again and again. Since it is a micro-feature, this will lead to a balkanization of micro packages, several packages doing more or less the same, more or less correctly. And concerning conversion of Float from decimal->binary representation, it'll be less ciorrectly, indeed it's very easy to do it wrong (not correctly rounded). 10 years ago, every SMalltalk dialect I know of did it wrong in any case... That's also why it should be a core service, and why it is in other languages (via scanf or other library) Back to the implementation, the decision for reifying the NumberParser was precisely: - to correct the parsing of Float which requires a little care to be correctly rounded (what every other language does right, Smalltalk did wrong) - to refactor a bunch of readFrom... selectors spreaded along the number hierarchy. - to correct discrepancies between the readFrom... variants (handling of separators, extra characters, error handling) So was it a good idea to factor Number parsing from several format? I cna agree on critiscism about the implementation: the NumberParser are ad-hoc hand crafted disconnected from grammatical formal description... Maybe what we need is a lower level service on which to build DSL parsers... But in any case, I think it's already better than what we had a few years ago. Cheers Nicolas > > 2014-02-26 22:38 GMT+01:00 Mariano Martinez Peck <[email protected]>: > >> Hi guys, >> >> When I export SmallDoubles with SIXX in GemStone it generates something >> like this: >> >> <sixx.object sixx.id="15" sixx.name="close" sixx.type="SmallDouble" >> >1.0000000000000000E-02</sixx.object> >> >> This is because "0.01 asString" -> '1.0000000000000000E-02' >> >> Then I want to load this in Pharo. So first problem is that of course >> SmallDouble doesn't exist. So I did: >> >> aSixxShapeChangeStream shapeChangers at: #SmallDouble put: Float. >> But then, SIXX use Float >> readFrom: aStream >> "Answer a new Float as described on the stream, aStream." ^(super >> readFrom: aStream) asFloat >> >> >> So, of course " Float readFrom: '1.0000000000000000E-02' " -> 1.0 >> >> So my 0.01 in gemstone become 1.0 in Pharo.... >> >> Am I doing something wrong or this is expected? What is the best >> workaround? >> >> In GemStone I could print the SmallDouble in the XML with a method like >> >> Float >> xmlRepresentation >> ^ String streamContents: >> [:strm | self printOn: strm base: 10] >> >> Is this the correct approach? If true, I guess I should define: >> >> Float >> sixxContentOn: aStream indent: level context: dictionary aStream >> nextPutAll: self xmlRepresentation >> >> >> Thoughts? >> >> Thanks in advance, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > >
