Re: The Next Mainstream Programming Language: A Game Developer’s Perspective

[Marcio]

Søren J. Løvborg wrote:
>> Software Frameworks The Problem: Users of a framework want to extend the 
>> functionality
>> of the framework's base classes!
>> The workarounds:
>> - Modify the source ... and modify it again with each new version
>> - Add references to payload classes, and dynamically cast them at
>>   runtime to the appropriate types. - These are all error-prone: Can the 
>> compiler help us here?
> 
> This is a problem I've only seen handled in the pretty obscure language 
> TADS, which had a "modify" keyword, which allowed user code to replace 
> entire methods of library classes, as well as add methods. Unlike the 
> traditional approach -- overriding the methods in a subclass -- this 
> affected all instances of the given class, also those instantiated in 
> library code.



	Smalltalk has always had the ability to add methods to existing 
classes, and even replace methods. This notion was organized better with 
more Software Engineering principles with ENVY/Developer from OTI (which 
was later bought by IBM and went on to produce VIsualAge for Smalltalk, 
VisualAge for Java and later what is now called Eclipse).

	Anyway, ENVY/Developer brought the notion of modules (applications) 
that could extend existing applications by adding 1) classes or 2) 
methods to existing classes. So, ENVY/Swapper, for example, was an 
application framework that added persistency. It pre-req'ed and extended 
the Kernel application and, among other things, added methods to class 
Object (Object was defined in Kernel).

	I believe Ruby may have been inspired by Smalltalk here and allows 
later code to add methods to existing classes a la Smalltalk. But I am 
not a Ruby expert, so check the facts for yourself.

	Replacing an existing method is always dangerous and was flagged in 
ENVY/Developer (if memory serves me well) as a conflict. This is more 
common for runtime system - patching is a clear example. Another clear 
example of runtime modification is AOP (Aspect Oriented Programming) 
where people can plug code into running code and do things like logging, 
profiling, code coverage analysis etc.

	Obviously CLOS people will probably say "we've been doing this for 
decades", even inserting a class C between A and B (inheritance-wise).

marcio