Andreas

Thank you for your detailed answer.

Andreas Raab wrote:
>> So we have in fact only 1652 -146 = 1506 classes in 3.8gamma
>> complexitiy wise.
> 
> 
> This is like some governments declaring that people above a certain age 
> without a job cannot be unemployed because they must be thought of as 
> being in "early retirement" ;-) In short I don't buy it. Since the 
> classes and methods appear in the user interface and therefore add to 
> the perceived (and real!) complexity of the system. 

When browsing I pay attention if the class name contains 'Test' or not.
And as Marcus Gaelli wrote, the new OmniBrowser (which is easier to 
customize than the old one) will be enhanced to selectively show only 
the test and nontest classes and methods.

If you argue that test classes add to the real complexity I cannot but 
wonder. The only thing they do is to make inherent complexity explicit.


> Sure, one would 
> *hope* that they add value by documenting behavior but there is a) 
> neither a guarantuee for that 

The itention of test classes is that they document the interface and 
serve as a quality assurance tool. If they do not do that they have
to be modified so that they satifiy this goal like other parts of the 
system.

 >
> and b) you would equally hope that all the 
> other classes add value by documentation behavior too. 

Surely in other classes there is documentation as well. I can learn a 
lot by browsing just the system. This has been so for a long time and 
still is. But if the programmer had not a precise perception of the 
subsystem he was working on (combining inside and outside viewpoints) it 
is often difficult to understand a framework. Test classes provide an 
outside view of a class or a subsystem. Just example categories on the 
class side are better than anything at all but often not sufficient.

 >
> And then should 
> we stop counting these too? ;-)

Well my point was just that complexity cannot be measured by counting 
classes alone and that I think that 3.8 is not more complex than 3.5. 
Actually the contrary. 3.8 is much a neater environment to work in. 
Especially with Monticello.


> So you consider something like 3D support not to be infrastructure. 
> That's a very interesting point of view; totally unlike to my own.

Infrastructure in the sense: Things needed for basic developing and 
loading other packages.
For doing development I do not need 3d support in fact.

But of course for the dyna book we need 3d. I used it from time to time. 
For this we have the full image. BTW what is the status of adapting 3D 
support for 3.8 Full?

We have to make sure that before releasing an image the packages listed 
for 3.8 full actually work.

There seems to be a problem with 3dBalloon and Wonderland (packaging). 
What is it actually? A pointer to a problem description?

> I 
> would have declared all of the basic media capabilities (graphics, 
> sound, 3D) to be infrastructure and instead argued that a system can 
> perfectly well run without the tests (you can load them if you wish to 
> develop in a particular subsystem)


The tests are documentation and quality assurance means. I do not want a 
system to come without that. For example for me it was important when I 
moved to 3.8 that I could run all SUnit tests immediately after 
downloading a new image. In fact doing this first froze the whole system 
for hours until I found out that the decompiling test does not run at 
all. When not selecting the decompiling test only about 12 of 1400 tests 
failed and my own ran fine. For me this was an encouragement to change 
to 3.8. Though I later find out that I cannot load the Verdana True Type 
font which I am using when doing presentations with Squeak. I will 
continue doing this in 3.6.

Basically this means that still more tests (not only Unit tests but 
others as well are needed. I reported the True Type font problem on 
Mantis http://bugs.impara.de/view.php?id=658  .

Having the tests in the base image slows down the rate of arbitrary 
change of interfaces because at least the tests have to be adapted as well.


 > or any single source-code management
> system. To me, programming is a particular use of the system not its 
> whole purpose for being
 > - that purpose is to be an environment for
> encountering dynamic media (which may or may not include programming 
> activities). 


We are speaking of the base image here and not of the full image.

 > But then, maybe I'm the only person actually playing the
> Squeak games, hm? ;-)

Probably not.

As was said in this thread elsewhere the goal still is that 
packages/subsystems can be loaded and unloaded easily so that finally 
the question if something is in the base image or not is not that important.


Hannes