2010/2/9 Mariano Martinez Peck <[email protected]> > > > 2010/2/9 Eliot Miranda <[email protected]> > > >> >> 2010/2/9 Mariano Martinez Peck <[email protected]> >> >> >>> >>> 2010/2/9 Luc Fabresse <[email protected]> >>> >>> Hi all, >>>> >>>> I wonder why BlockContext>>fixTemps is still in PharoCore. >>>> I guess that it should be removed, isn't it? >>>> >>> >>> I would like to remove them. >>> >>> >>>> It has only one sender. >>>> >>> >>> Yes, in the core ;) But the problem is that Seaside (I think only 2.8.4 >>> as 3.0 seems to fixed that) or KomHttpServer are still using it. >>> >>> Of course, we can just remove it and assume that those external packages >>> should be fixed to run on Pharo. Squeak trunk also has closures...so.. >>> >>> >>>> Morever, should the BlockContext class be removed too? >>>> >>> >>> I would like, too. The only problem is the "compatibility". What maybe >>> can be done is to remove the class but do something like >>> >>> Smalltalk at: #BlockContext put: #BlockClosure >>> >> >> I think this is a really bad idea. Imagine loading something that adds >> functionality to BlockContext that simply makes no sense in BlockClosure or >> breaks when compiled on BlockClosure. Best live with the differences and >> upgrade than introduce a horrible hack that pretends to do >> backwards-compatibility but actually confuses the hell out of people. >> >> > :( So...what do you recommend us Eliot ? >
Leave BlockContext there for now. Port functionality in BlockContext to BlockClosure as required. In a few months (or perhaps even now) mark BlockClosure>>fixTemps and BlockContext protocol as deprecated so that uses of fixTemps and BlockContext generate warnings e.g. in the Transcript. In a few years get rid of BlockContext. Right now all we're talking about is having a null implementation of fixTemps in BlockClosure. Marking this deprecated seems to be adequate. Or am I not understanding your concerns? Later on, in synchrony with Squeak and eToys I would like us to consider whether it is worth-while collapsing ContextPart and MethodContext into a single class called something like Context or SmalltalkExecutionContext or ExecutionContext or ThisContext. > > HTH >> >> >>> >>> But I have no idea the impact of this.... >>> >> >> which is one really good reason /not/ to do it :) >> > > ahahhaha that's true :) > > >> >> best >> Eliot >> >>> >>> >>>> >>>> Depending on answers, I will write a bug report. >>>> >>>> Luc >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [email protected] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [email protected] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
