On 03.01.2012 15:44, Igor Stasenko wrote:
On 3 January 2012 15:21, Ben Coman<b...@openinworld.com> wrote:
I am reminded of an article "Things You Should Never Do" [1] by one of my
favourite authors. This is not to discourage the clean out and
re-architecture of Pharo which is overall a good thing, but just to consider
the downside and risk as a counter-point. Certainly Pharo is more evolving
than starting from scratch...
And then I got sucked into reading another (perhaps offtopic) article
"Painless Functional Specifications" [2] that some may find interesting
[1] http://www.joelonsoftware.com/articles/fog0000000069.html
[2] http://www.joelonsoftware.com/articles/fog0000000036.html
yes, a new is not necessary better than old.
In the case of
- Announcements vs Events,
- FileSystem vs. FileDirectory&Friends
- Opal vs. current Compiler
I would say there's a strong case for considering the new alternative
"better".
And if you ask me, i never throw away stuff, just because it is 'old'.
if its in good condition and still can be used,
why we should throw it away?
Why should be throw the old ones away you ask? We shouldn't.
We should, however:
a) Migrate code in core to use new systems.
b) Repackage old systems to be unloadable/reloadable for external
projects who still rely on them.
c) Remove them from core, leaving one choice by default for building
code using such systems, reducing confusion.
d) Introduce namespaces, so folks who don't like the versions of those
systems existing in core capable of loading alternate versions without a
massive renaming effort.
As for the question, what belongs in a Core image?
Well, I for one would like compiler/decompiler in there.
I'd also like an easily modifiable/understandable one. Haven't really
read the current one, nor Opal enough to have an educated opinion on
which is "better" in those regards, but others seem to.
If that Compiler requires an AST, yes, it should be in Core.
I'd also like the ability to write a sources file, but decoupled from
the presence of a Compiler in a way which make me able to unload it if I
don't need it. (say, for a minimal image)
Doing so in a clean way sort of requires an event-system, my choice for
that would be Announcements.
It also requires interacting with the file system. So I'd like a system
doing that in Core as well.
A graphical framework? Sure.
Tools written in the GUI to modify/inspect the system from within the
image? Absolutely.
Refactoring? While I like it, I don't think it's important enough to
necessarily include in a "Core" image. (Full image? Absolutely)
Syntax highlighting? Same as refactoring.
As for dealing with systems also existing as external packages, in
addition to d) above, I 100% agree with Nortbert's mail.
I don't see why one could not work out solutions for synching with
external repositories in addition to the Pharo-specific one, and/or
introduce extensions used in Pharo as just that, extensions.
Cheers,
Henry
IOW; A bit late perhaps, but I don't think the merge of Full and Core
was a good thing, and would rather if the image builder took care of
such tasks...
As long as the packages are "pure" in the sense they contain no
overrides, there is no reason one could not work on/commit fixes to the
Core parts of the system from a "Full" image if one felt the
tools/functionality included in Full are worth it.
