Igor Stasenko wrote:
On 3 January 2012 14:35, Lukas Renggli <[email protected]> wrote:
What I'm NOT saying: Kernel and Tools should be coupled. (If ppl whant
kernel+other things, they are welcome to have it... I myself will want it)
This coupling is exactly what is happening. How do you propose to
build your kernel+other distribution?
What coupling you are talking about? Can you give an example?
Instead we striving to decouple components of the system and improve
infrastructure.
If you speaking about announcements, so here the vision:
- there are tons of different event driving mechanisms in image
and we want to leave only one, replacing all of them with announcements.
Will this couple tools to announcements? Of course.
Will this add unnecessary coupling between layers? No. Because
announcements is inherently
serving for decoupling event source(s) from event consumers.
THis is not about announcements. I am talking about adding new UI,
FileSystem, Refactoring, Compiler, Tools, ... frameworks. Any such
addition will increase the coupling in Pharo because the core and
external clients will start to slowly adapt these frameworks. This
adaptation increases the coupling (to this particular framework) and
means that it will be increasingly hard to unload or replace them in
the future.
Or shorter: What you add today, you cannot easily remove again tomorrow.
i don't understand your concerns here.
if we replacing old compiler with a new one, should external clients
adapt new compiler?
sure they should. but they will only benefit from that. so i don't see
what are problem here?
and about unloading.. do you think it will be worse than in existing system?
or you suspect that we're not caring about that in new frameworks design?
again, i don't really understand what is your concerns grounded on.
should we stop improving system because any change have a potential
risk of breaking someone's code?
Lukas
--
Lukas Renggli
www.lukas-renggli.ch
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
