While we're at it, I committed a tiny change to the assertions in
PPAbstractParserTest, so that assertions return the parse result. I
needed it for cases where I don't want to compare to an expected
result, but still make further assertions than just "yup, it parses".
For Coral I also wrote a simple PPDelegateParser subclass that applies
its inner parser to the stream first element.
It's like:
PPPredicateObjectParser>>matching: elementParser message: aString
^ self
on: [ :each | elementParser matches: each ]
message: aString
BUT: it will return the parse result of its inner parser, rather than
the accepted element as-is.
I use it to parse the argument array in a Coral script, some arguments
are expected to be integers or other parseable. It allows me to
predefine a bunch of utility parsers for simple argument types, that
return a ready-to-use object.
If you want to see the code, it's PPElementParser in the Coral package
http://www.squeaksource.com/Coral.html
but mostly it looks like this:
parseOn: aStream
| result |
aStream atEnd ifTrue: [ ^ PPFailure message: 'element expected' at:
aStream position ].
result := parser "end" parse: aStream uncheckedPeek.
^ result isPetitFailure
ifFalse: [
aStream next.
result ]
ifTrue: [
PPFailure
message: (message ifNil: ['error: ' , result
printString , ' in element'])
at: aStream position ]
What do you think? I'm still not sure what the best way is. I
hesitated between subclassing PPDelegateParser, PPLiteralParser… maybe
a factory method in PPPredicateObjectParser would work as well:
--
Damien Pollet
type less, do more [ | ] http://people.untyped.org/damien.pollet
