could introduce isSingleQuote in Character

[Ducasse]

Because this is useful for building scanners and other lexers.

[guillep]

What if it is packaged in a separate package?
I think we both agree that we do not like parsing code crippling into string (we have suffered that for a long time...) ^^

[Ducasse]

why not now are we really about on method while did you look at the 15 methods introduced by unicode that I'm pretty sure we will never use?
Check the testing-unicode to see what I mean.

did you check the API?
See below because more than half of it is not really useful.

Writing character = $' and = $" in all kind of places is not really nice.
And these characters are really tight to our syntax.

Of course I packaged it in my package and can not care at all.

#(#< #= #> #alt #asCharacter #asHTMLString #asInteger #asKeyCombination #asLowercase #asShortcut #asString #asSymbol #asText #asUnicode #asUnicodeChar #asUppercase #asciiValue #basicIdentityHash #basicPharoToIso #basicSqueakToIso #canBeGlobalVarInitial #canBeNonGlobalVarInitial #charCode #characterSet #codePoint #command #control #copy #ctrl #deepCopy #digitValue #fuelAccept: #gtInspectorCharacterIn: #hash #hex #hexDigitValue #isAlphaNumeric #isArrow #isCasedLetter #isCharacter #isClosePunctuation #isCompletionCharacter #isConnectorPunctuation #isControlOther #isCurrencySymbol #isDashPunctuation #isDecimalDigit #isDigit #isEnclosingMark #isFinalQuote #isFormatOther #isInitialQuote #isLetter #isLetterModifier #isLetterNumber #isLineSeparator #isLiteral #isLowercase #isMathSymbol #isModifierSymbol #isNonspacingMark #isOctetCharacter #isOpenPunctuation #isOtherLetter #isOtherNumber #isOtherPunctuation #isOtherSymbol #isParagraphSeparator #isPrivateOther #isSafeForHTTP #isSeparator #isSpaceSeparator #isSpacingCombiningMark #isSpecial #isSurrogateOther #isTitlecaseLetter #isUppercase #isVowel #join: #largeIdentityHash #leadingChar #lowercase #macRomanToUnicode #meta #printOn: #printStringHex #sameAs: #serializeOn: #setValue: #shallowCopy #shift #shouldBePrintedAsLiteral #stonOn: #storeBinaryOn: #storeOn: #to: #tokenish #unicodeToMacRoman #uppercase #veryDeepCopyWith:)

[Ducasse]

And you see in my parser I do not use = $' but
RBScanner or STONReader could benefit from it.

[guillep]

why not now are we really about on method while did you look at the 15 methods introduced by unicode that I'm pretty sure we will never use?

Yes, it would be nice to clean them :(
I'm seeing now the list of not so useful testing methods in Character, plus a lot of leadingChar dead code...

And you see in my parser I do not use = $' but
RBScanner or STONReader could benefit from it.

Ok, so the point is how do we share that behaviour between many parsers? I'm not saying that the method you propose shouldn't be in the image. It can be in a separate package and still in the base distribution. I'm just suggesting it should not be mandatory in the bootstrap (as String is...) :).

For example, we could have a ParsingExtensions package with convenience methods in both Character and String for example. No? And RBParser/STON could use that...

Maybe I can take Character cleaning as one of my solo projects in my new isolated office

[Ducasse]

I started to group the Unicode method in a specific protocol.
Indeed for the bootstrap we could remove really many methods.
Yes we can have parsingExtensions.

Looking at any core classes you will find ways to improve it. I was reading superficially the Parser class and it had dead code and method that should be moved to subclass. I was not happy also with the parser tests.