Hi nicolas.
No it's not strange.
2 different parsers respond to 2 different syntax and expectations.
To me it's quite clear:
- The SmalltalkNumberParser was there to parse a Smalltalk syntax
(badly named SqNumberParser in the ages...)
It should do this thru Number readSmalltalkSyntaxFrom: '1.0e4'
- The ExtendedNumberParser was there to parse an extended syntax
(the one most apps handling data from oustide world will wish to parse).
It should do this thru Number readFrom: '1.0e+4'
I have a question: is ExtendedNumberParser parsing SmalltalkNumberParser
numbers?
Because we could use by default ExtendedNumberParser.
Else we can have an external package to maintain ExtendedNumberParser
part of the ecosystem.
- The FortranNumberParser was just an unused experiment.
Its sole goal was to expose an example of how a GenericNumberParser
could be subclassed.
Such class has a better place in a cook-book than in the image, so
Bye bye.
We could add it to the PharoExtras.
Date readFrom: '2015/02/06' readStream does not have to follow a
Smalltalk syntax, so why Number readFrom: '1.0e+4' readStream would
have to?
As Yuriy underlined, we might extend the Smalltalk syntax to embrasse
some of external world patterns, why not, but it's limited and is
going to be a problem with formats like '.2' or '2.e0'.
Whether the extended parser should be in the core image or not is a
valid question.
We all agree that Pharo is all but finished and need to be constantly
cleaned up.
The challenge is how can Pharo change but remain
application-writer-friendly?
So two different things are:
- the value of the feature: is it worth maintaining it or not?
If yes, should it be maintained outside the core, or inside by the
Pharo-team?
I agree that removing incomplete features is a valid strategy when
the team is too small
- the quality of implementation
And there are two ways of cleaning:
- clean a dirty implementation, but keep the feature (eventually with
a different API)
- remove the feature, based on a value/cost analysis
Here, I feel like it's the dictatorship which sounds questionnable.
Were the feature understood?
There were unit tests and class comments, so pretending to not
understand is not really an excuse.
Were the value of the features discussed?
Maybe in a small core team... From outside, we don't really know.
No discussion should happen in the mailing-list but the problem is that
the mailing-list is like a stream.
I forget things. This is why we should have a better process but if I
could get less things to do it would also
help me a lot (and I do not mean pharo things :)).
Were an externalisation of the feature and transfer of maintenance to
a 3rd party discussed?
I'm not aware of. I'm sure it would have been a better decision.
So from my POV, such decision process remains to improve. It sounds
too light and arbitrary.
In some cases, I have the impression that the volunty of cleaning is
too much dogmatic.
I agree. This happens when we are too mcuh stress. When I feel that I
want to throw away half of the system (menu, fonts... and many others :))
I just close pharo and do something else
I agree that too much pragmatism won't lead to a clean image any time
soon...
I agree that Pharo team has a licence to change things and should
decide, otherwise let's all stick to Squeak ;)
But a bit of democratie, argumentation and COORDINATION does not hurt.
Yes.
Then how can user support be improved?
- Is it possible to write release notes helping the transition?
(were is located the add-on package that enables compatibility, who
maintains it, is there a new and better API, etc...)
- Could some automated AST-based refactorings be prepared and applied
auto-magically?
It's not necessarily the sole business of Pharo-team, user community
could help writing such notes.
So what would be a reasonable plan.
I have no problem to maintain a nice package in PharoExtras if it helps.
Stef
