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 > -- Best regards, Igor Stasenko.
