Ok done in Kernel-LucFabresse.578 (PharoInbox). BlockContext>>fixTemps and BlockClosure>>fixTemps have been deprecated. Issue: http://code.google.com/p/pharo/issues/detail?id=1947
Luc 2010/2/9 Eliot Miranda <[email protected]> > > > 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 >
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
