On 25 April 2010 10:45, Nicolas Cellier <nicolas.cellier.aka.n...@gmail.com> wrote: > 2010/4/25 Igor Stasenko <siguc...@gmail.com>: >> imo, it should look like: >> >> readFrom: stream >> ^ readFrom: stream pattern: ISO8601 >> >> and >> readFrom:pattern: >> > > Yes, and next step will be to optimize with a pre-compiled pattern > (may use a cache). > Otherwise, when you have a bunch of String to convert in DateAndTime, > you're spending time in parsing the same pattern repeatedly. >
Sure... piece of cake: ISO8601 := DateTimePattern compileFrom: 'xyz...[]./s]wefj..' And readFrom:pattern: could check that: compiledPattern := pattern isString ifFalse: [ pattern] ifTrue: [ DateTimePattern compileFrom: pattern ]. > Nicolas > >> should parse date by taking an arbitrary pattern into account. >> We could invent own syntax for a pattern, or use other invented ones >> (from C, Perl etc), >> and implement a separate DateTimeParser class. >> >> The messy code like this >> aStream peek = $- ifTrue: [ aStream next. bc := -1] ifFalse: [bc := 1]. >> year := (aStream upTo: $-) asInteger * bc. >> month := (aStream upTo: $-) asInteger ifNil: [1]. >> day := (aStream upTo: $T) asInteger ifNil: [1]. >> hour := (aStream upTo: $:) asInteger ifNil: [0]. >> >> should be put in trash! :) >> >> On 24 April 2010 23:05, Stéphane Ducasse <stephane.duca...@inria.fr> wrote: >>> What I did was to stick with the ISO parsing and added a fuzzy readfrom >>> (the previous one in pharo) >>> so that readFrom: read only iso but well and fuzzy tries to find its way >>> with strange input. >>> >>> Stef >>> >>> On Apr 24, 2010, at 9:48 PM, Nicolas Cellier wrote: >>> >>>> 2010/4/24 Julian Fitzell <jfitz...@gmail.com>: >>>>> On Sat, Apr 24, 2010 at 10:54 AM, stephane ducasse >>>>> <stephane.duca...@free.fr> wrote: >>>>>> >>>>>> What are the expectation for DateAndTime>>readFrom? >>>>> >>>>> Personally, my expectation is that it doesn't exist. :) >>>>> >>>>> To believe that there is a single way of parsing strings into dates (or >>>>> numbers, or anything else) that will be appropriate in all cases is pretty >>>>> silly. It would seem much better to me to have configurable parsing >>>>> classes. >>>>> >>>>> Julian >>>>> >>>> >>>> Sure, that might be usefull, however current implementation intention >>>> clearly seems related to >>>> http://en.wikipedia.org/wiki/ISO_8601 >>>> >>>> Nicolas >>>> >>>>> _______________________________________________ >>>>> 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 >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project