[Pharo-project] fixTemps and BlockContext question
Hi all, I wonder why BlockContext>>fixTemps is still in PharoCore. I guess that it should be removed, isn't it? It has only one sender. Morever, should the BlockContext class be removed too? Depending on answers, I will write a bug report. Luc
True, that is not needed anymore. The normal procedure is to first deprecate the method and later remove it. There are certainly many clients (e.g., from Seaside apps) that send the message and first need to be adapted. So, yes, please create a report and post a patch. Thanks, Adrian On Feb 9, 2010, at 13:54 , Luc Fabresse wrote:
Hi all,
I wonder why BlockContext>>fixTemps is still in PharoCore. I guess that it should be removed, isn't it? It has only one sender.
Morever, should the BlockContext class be removed too?
Depending on answers, I will write a bug report.
Luc _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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 But I have no idea the impact of this....
Depending on answers, I will write a bug report.
Luc
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
mmmm I found this old issue: http://code.google.com/p/pharo/issues/detail?id=1058 On Tue, Feb 9, 2010 at 2:03 PM, Mariano Martinez Peck <marianopeck@gmail.com
wrote:
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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
But I have no idea the impact of this....
Depending on answers, I will write a bug report.
Luc
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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. HTH
But I have no idea the impact of this....
which is one really good reason /not/ to do it :) best Eliot
Depending on answers, I will write a bug report.
Luc
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
 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.
Seaside 2.7 uses #fixTemps. Seaside 2.8 and 3.0 should use #fixCallbackTemps, which is a Seaside specific implementation of #fixTemps. Lukas -- Lukas Renggli http://www.lukas-renggli.ch
2010/2/9 Eliot Miranda <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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 ? 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Eliot Miranda <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Eliot Miranda <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Eliot Miranda <eliot.miranda@gmail.com>
2010/2/9 Mariano Martinez Peck <marianopeck@gmail.com>
2010/2/9 Luc Fabresse <luc.fabresse@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (6)
-
Adrian Lienhard -
Eliot Miranda -
Luc Fabresse -
Lukas Renggli -
Mariano Martinez Peck -
Stéphane Ducasse