[squeak-dev] Evolution from the primordial stew (was: The Trunk: System-dtl.609.mcz)

Casey Ransberger casey.obrien.r at gmail.com
Sun Oct 27 07:33:46 UTC 2013


Hannes: yes, only in this case the "data" has behavior too:)


On Sat, Oct 26, 2013 at 12:11 PM, H. Hirzel <hannes.hirzel at gmail.com> wrote:

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


More information about the Squeak-dev mailing list