[squeak-dev] Re: problem with filein
Trygve Reenskaug
trygver at ifi.uio.no
Fri Aug 13 10:13:16 UTC 2010
We had two methods for initializing on the class side in OOram:
|initialize |and |tmInitialize|.
* |initialize |initialized the class as a stand-alone entity. It
only used the class library and was independent of any of the
application classes. It could be called at any time during filein
and must be called for all classes before |tmInitialize|.
* |tmInitialize |initialized the class as a member of an
application. It assumed that all application classes had been
filed in. This meant that a class variable could be an instance
of an application class.
All class initialization methods were modified so that hey could be
repeated at any time.. A service method initialized all classes; it was
typically called before saving an image.
Just my two cents worth
--Trygve
On 2010.08.12 21:20, Bert Freudenberg wrote:
> On 12.08.2010, at 20:48, Andreas Raab wrote:
>
>
>> On 8/12/2010 10:44 AM, Jecel Assumpcao Jr. wrote:
>>
>>> So the file in had actually worked just fine, but at this point deleted
>>> all the instance methods that had just been created. This might cause
>>> problems for others, but I didn't call it a "bug" since each part is
>>> correct in itself. Perhaps there should be a warning for 1? I imagine
>>> that would be annoying and even scary when loading stuff out of order.
>>>
>> What do you think about implementing ProtoObject class>>initialize as an empty stub? This would act as a backstop for situations like these.
>>
>
> It should not be empty but an error message "Never send initialize to super on the class side!"
>
> - Bert -
>
>
>
>
--
Trygve Reenskaug mailto: trygver at ifi.uio.no
Morgedalsvn. 5A http://heim.ifi.uio.no/~trygver
N-0378 Oslo Tel: (+47) 22 49 57 27
Norway
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20100813/e87da61b/attachment.htm
More information about the Squeak-dev
mailing list
|