Object Technology & Resources Summary

** Efficiency, Flexibility & Classes

The discussion mentioned the trade-offs required to balance efficiency and flexibility. Concerns about 
making unnecessary calls to objects which may not implement a specified method was countered with the 
fact that broadcasting requests can often be more efficient than implementing suitability tests.

It was also pointed out that it is better to build an object in runtime from appropriate classes using 
predefined methods. An 'upgrade flag' would be present in the system: objects could be 'frozen' to assist 
with performance, but re-built by the object manager during each upgrade. Classes unable to fulfil a 
functional requirement are ignored - this leaves a missing function, but is highly unlikely to cause 
anything to fail.

Properties of objects shouldn't be restricted in general - UI characteristics, for example, could 
legitimately be inherited by 'non-UI' objects in order to, say, provide display and user-interaction 
parameters. Developing hybrid weirdity (great term!) is another reason for being able to want methods 
mutating, but without the object code changing. A functional flow interface with user interaction provides 
an example of this: streaming data and live interaction with adaption being performed - methods adapting 
to the quality and quantity of data to change the visualisation. Dynamic artwork is also mentioned, as is 
being able to change colour representation or whatever. To quote Paula Lieberman:

	"let's add some purple dye up there at time N, and at time N+1 change the dye to yellow, and
	when I press the Escape key, make it violent chartreuse with an A minor chord on a organ sample
	at fff....."

In essence, you need to be able to ensure the flexibility is there to cope with the things we didn't 
originally anticipate. [John's note: truly creative stuff comes from really bending things totally out of 
shape - if you can't do that, creativity is limited]. The needs of users can often be different from the needs 
of programmers, which suggests we must make it easy for developers to create the software the users 
want, and not their own 'toy pet'.

** Selfmodifying Code

Comments on selfmodifying code spawned some interesting points. Experience of LISP has given a sour 
opinion of selfmodifying code to many, and it is indeed a bad idea in most cases (selfmodifying code, that 
is - not LISP!). Modern computers, with varying cache capabilities, can easily have performance 
degraded by selfmodifying code. Well, if you do it wrongly it can - but if you do it right it can improve 
things quite considerably. [John's note: compare to the issue of 'goto' - while a bad thing for almost all 
situations, it does have its uses when handled properly].

The cache problem can be handled sufficiently by flushing the first level cache. However, as cache sizes 
get bigger and more processors are added you have more caches to flush. The Intel Merced, for example, 
will probably have an 8 MB cache, and be present in multiple-CPU configurations.

Furthermore, it's important not to get confused about what selfmodifying code is:  it's code directly 
changed during execution. However, if this code is actually rewritten to cover different cases as multiple 
sections of code accessed through conditional branching you can develop alternatives for most uses of 
selfmodification without cache problems and the like which can degrade performance. Of course, you 
could create versions of functions/methods for a given system and just swap a pointer to direct code to the 
right method - selfmodification would then only occur at the moment code is first loaded up. It was 
mentioned that selfmodification should even be physically forbidden through techniques such as write-
protection of memory.

Are some of us trying to out-optimise modern optimising compilers by any means necessary? Apart from 
keeping code compact (not really much of a necessity these days and still achievable through other means) 
selfmodification can be replaced by more considered, structured programming approaches. 

** Structured Programming 

Ah, structured programming... In particular, criticism about universities and other institutions 
(particularly in the west) not placing enough emphasis on structured design and programming techniques. 
[John's note: Oxford Brookes University, UK taught me structured programming and design with great 
emphasis, so not all universities are bad].

Good languages mentioned for teaching structured programming included Pascal and Modula-2 (praise to 
Wirth!) as well as Java, while C and C++ came under fire for being unnecessarily complex, 
unstructured and unfriendly. C++ has also helped destroy some companies, apparently! [John's note: 
Sounds like C++ and ISO 9000 are related...]


--=_=8<==MD236FCC7A3-1EFDE8CC==8<=_=--