2011/8/8 Stéphane Ducasse <[email protected]>: >> >> >> OK, some clean up was required, but you see, you can make things worse >> when cleaning... > > Yes but in average this is really not the case. > >> It's like Pharo cleaning removed the antidote, but forgot to remove >> the poison... > > Ok that kinds of things happens in ugly, undocumented, obsolete systems. > >> Now, of course, instead of a local polishing, it would be possible to >> rewrite all. > > I'm starting to write tests for the events. Now since you are at it, I guess > that you read this wonderful code > full of hypothesis and other subtle strange behavior. So I'm quite sure that > they will be problems. > But we will fix them. Else we should stop now and do Javascript because at > least we will look cool. >
Oh, If your goal is to remain popular, then indeeed, you should keep away from changing such parts of the system which are not shining ;). The obvious reason is that multilayer hacks with obfuscated contracts are not maintanable... so it's inevitable to create bugs in the transition and harvest complaints... Of course, if your goal is to make the system more simple and maintanable, I'm with you (and I know it is). But don't forget to extract the positive part of complaints that will help you making the system better. Personnally, the finite state machine logic in Squeak/MouseOverHandler is well beyond my understanding. So I could not clean it easily myself, A cosmetic cleaning was attempted in Pharo.I have nothing against that. I just pointed a problem in current cleaning, so it just have to be finished. The stincky ivar mutation already was in Squeak. I just said that it should raise an alarm in coder's eyes in the future and I hope this helps. Otherwise I can also shut up. The second approach suggested by Igor is more involving, consist in a full rewrite, probably with these stages: - gather description of the features to be supported, - an inventory of third party interested in this kind of features, - and from there, decline a new definition of contracts. >> But please, don't do it blindly and loose 2 third of features like the >> new implementors window :( > > We are not doing things blindly: > > First it costs us money, time and we should all the lucky that Ben was > really good and enjoy rewriting us boring UI > without a decent widgets set (because he fixed them also the > multiselection and others). > Benjamin I publicly thank you for all the good stuff you did!!!! > > > Second, what are these 2 thirds that we lost? Because two third is a > lot. I'm dreaming to throw away two third of the stringHolder hierarCrap > Please hightlight me. > > Sorry but I do not like this kind of statements because there are false and > because we work hard to bring to life > a system full of shit. Shit that was accumulated and of course stable because > it did not move since years. > In addition if everytime a guy spend 4 months to build a new tools we all > complain (without constructive points to help him fixing that) > better say to students that they are idiots and that we do not need their > help. But in that case be ready to be with the same ugly system > in the future. And we do not accept that. So there will be some glitches but > we are stronger than them and we will fix them. > > Nicolas I'm quite sure that you would not say that around a beer to benjamin > because I know you so pay attention because > Ben is also one of the coolest students we got recently and we really liked > his spirit and atttitude. Jumping in StringHolder and broken/duplicated > widgets > is not easy, nor it is to work on bootstrapping Pharo. > > Stef > > Sure, I don't want to restrain goodwill. But as a user of the service I don't see all the sweat the hardworkers put into the system, I just see a regression that makes my life harder (I simply cannot track the messages with the new windows). And obviously, comparing the length of old menu with new one, two third does not seem exagerated to me. But maybe you don't work with those tools and install OB/RB after each update... Nicolas >> >> Nicolas >> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> >> > > >
