SYSTEM WARNING: Creating default object from empty value

SYSTEM WARNING: Creating default object from empty value

Mantis - Squeak
Viewing Issue Advanced Details
5783 Kernel minor N/A 01-19-07 10:38 04-27-09 15:14
new 3.10  
0005783: [RFI] Needed a way to condense sources/changes that preserves version trails better.
Currently when changes or sources are condensed the result contains nothing but the current version of a method.
At that point you cannot distinguish between a method that never had a prior version. And one that had a prior version but that was removed duing the condensing process.

In other words the audit trail of versions is broken.

The should be an option that would allow you to condense, yet preserve the most recent prior version of method source in the condensed files.
This would help in debugging.

You would be able to know at a glance if a method with a recent time stamp was new. Or a trivial change on a previous method. Or if it was a major change.

Change of ownership of a piece of code is also a good clue.

Squeak code gathers a lot of clutter. Sometimes discernment is important to knowing what can be done to repair code.

Yours in service, --Jerome Peace

related to 0005205resolved  Versions, sources, and changes. Repairing the current system to eliminate limitations. 
related to 0002514closed  [FIX] condenseSources (was: Re: [Q] Removing changes file content.) 

12-03-08 21:31   
this is needed to support method overrides in Monticello.

When loading/unloading Monticello overrides, it goes looking for the previous version that doesn't have a "*" prefix (i.e. the non-overridden version) If only one version is preserved then it cant find it.

12-18-08 08:22   
@wiz: I'm working on a project which allows one method per package per class (OT: and a lookup order).
your requirement, in my project, would mean that only one source method per package per class survives condensing. would that be sufficient for your needs?

@Keith_Hodges: cannot understand your comment, want to disambiguate "this". TIA.
12-21-08 04:38   
Hi Kwl,

One method per package per class. This sounds like a step in the right direction. When I wrote this complain I was not originally thinking of the impact of packages and classes.

One method per package per class would help some. Two versions of every method with at least two versions is more what I had in mind.