[Pharo-project] glamour and pharo
btc at openInWorld.com
Tue Jan 3 15:21:23 CET 2012
Igor Stasenko wrote:
> On 3 January 2012 14:35, Lukas Renggli <renggli at gmail.com> 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
>>> 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 Renggli
I am reminded of an article "Things You Should Never Do"  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"  that some may find interesting
More information about the Pharo-project