thanks luc! Stef
On Feb 10, 2010, at 10:00 AM, Luc Fabresse wrote: > 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 _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
