[Pharo-project] fixTemps and BlockContext question

Eliot Miranda eliot.miranda at gmail.com
Tue Feb 9 17:20:19 EST 2010


2010/2/9 Mariano Martinez Peck <marianopeck at gmail.com>

>
>
> 2010/2/9 Eliot Miranda <eliot.miranda at gmail.com>
>
>
>>
>> 2010/2/9 Mariano Martinez Peck <marianopeck at gmail.com>
>>
>>
>>>
>>> 2010/2/9 Luc Fabresse <luc.fabresse at 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 at lists.gforge.inria.fr
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>>
>>>
>>>
>>> _______________________________________________
>>> Pharo-project mailing list
>>> Pharo-project at lists.gforge.inria.fr
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project at lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project at lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.pharo.org/pipermail/pharo-dev_lists.pharo.org/attachments/20100209/c99d925b/attachment.html>


More information about the Pharo-dev mailing list