[Pharo-project] glamour and pharo

Ben Coman 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
>>> 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




More information about the Pharo-project mailing list