<div dir="ltr">Hannes: yes, only in this case the "data" has behavior too:)</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Oct 26, 2013 at 12:11 PM, H. Hirzel <span dir="ltr"><<a href="mailto:hannes.hirzel@gmail.com" target="_blank">hannes.hirzel@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This phenomenon is not all that unknown to people who have maintained<br>
a db system with application programs accessing it for many years.<br>
There is data which once was entered and is no longer used and<br>
updated. Often people are not aware of it and if they are they mostly<br>
do not dare to delete it.<br>
<br>
Any complex system needs to be reviewed from time to time if you want<br>
to maintain service quality.<br>
<br>
--Hannes<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 10/26/13, Casey Ransberger <<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>> wrote:<br>
> There are two sides to this coin, and I didn't see that before reading this.<br>
> I only saw the downside.<br>
><br>
> "Rogue objects" are generally something that freaks me out and makes me<br>
> nervous. Are they still sending messages? Will they? Are they still<br>
> receiving messages? I don't like that they're hard to find, mainly.<br>
><br>
> I've had some long nights realizing that there were stored procedures hidden<br>
> away in databases at work, and this is a bit like that except... the<br>
> database isn't disjoint from the running "application" and...<br>
><br>
> This is what I've really enjoyed, reading this post: since we never<br>
> blanket-discard runtime state as in other systems, what would there be<br>
> "useless dangerous dead state-process" is still useful here because it can<br>
> contain forensic/historical information.<br>
><br>
> Or, maybe more clearly: some of the design goals underlying this system were<br>
> specified by people who were interested in anthropology, people who wouldn't<br>
> be interested in throwing the mummy out with the bath water. To abuse a<br>
> phrase.<br>
><br>
> Fascinating. I have a new perspective.<br>
><br>
> On Oct 26, 2013, at 7:35 AM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
><br>
>> On Sat, Oct 26, 2013 at 07:55:25AM +0000, H. Hirzel wrote:<br>
>>> What is NextVariableCheckTime used for? Is it that there is no active<br>
>>> use of it anymore?<br>
>>><br>
>>> --Hannes<br>
>><br>
>> It was used a long time ago to schedule periodic checks of something.<br>
>> I'm not sure what it was, but it may have been related to handling the<br>
>> state of variables during copies to or from image segments.<br>
>><br>
>> The class DeepCopier is of course an object, and that object has been<br>
>> in the image for a long time. By looking at that object, you could<br>
>> see that it pointed to a value that happened to represent a time stamp,<br>
>> and since that time stamp represented a time in 2001, it was a pretty<br>
>> good clue as to when the variable had last been updated.<br>
>><br>
>> I was only pointing this out because it reminded me once again of how<br>
>> different Squeak is from environments that think of everything as file<br>
>> based source code, rather than as objects.<br>
>><br>
>> Dave<br>
>><br>
>>><br>
>>> On 10/26/13, David T. Lewis <<a href="mailto:lewis@mail.msen.com">lewis@mail.msen.com</a>> wrote:<br>
>>>> On Fri, Oct 25, 2013 at 10:58:49PM +0000, <a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a><br>
>>>> wrote:<br>
>>>>><br>
>>>>> Item was changed:<br>
>>>>> Object subclass: #DeepCopier<br>
>>>>> instanceVariableNames: 'references uniClasses newUniClasses'<br>
>>>>> + classVariableNames: ''<br>
>>>>> - classVariableNames: 'NextVariableCheckTime'<br>
>>>>> poolDictionaries: ''<br>
>>>>> category: 'System-Object Storage'!<br>
>>>><br>
>>>> One thing that I find rather appealing about Squeak is that its stew of<br>
>>>> living objects contains things that have existed since before my time.<br>
>>>> Even if the so-called "code" changes, the objects still can survive.<br>
>>>><br>
>>>> Every once in a while this turns out to have some practical benefit.<br>
>>>> For<br>
>>>> example, the class DeepCopier had a class variable that kept track of<br>
>>>> some<br>
>>>> sort of time stamp (in the form of NextVariableCheckTime seconds). Some<br>
>>>> time in an earlier millenium, a primeval user of the class had set this<br>
>>>> variable, then wandered off into a tar pit. We do not really know who<br>
>>>> that<br>
>>>> may have been, but the original object (class DeepCopier) has survived<br>
>>>> in<br>
>>>> the image, and the last updated value of its NextVariableCheckTime has<br>
>>>> remained undisturbed since those early days. Thus when I became curious<br>
>>>> about whether this class variable was being used, I was able to look at<br>
>>>> its value and convert it to a DateAndTime to see that it had not been<br>
>>>> updated in the last dozen years or so.<br>
>>>><br>
>>>> It's a small thing, but just try keeping track of that with a version<br>
>>>> control system.<br>
>>>><br>
>>>> Dave<br>
>>>><br>
>>>><br>
>>>><br>
>><br>
><br>
><br>
<br>
</div></div></blockquote></div><br></div>