Reflective Support in Spoon

Craig Latta craig at
Tue Mar 22 19:11:08 UTC 2005

Hi Alexandre--

 > I am interested in the impact of having reflective support in the core
 > of the language. Is it a good strategy to completely remove
 > reflection? How much space would be gained?

	Which classes/methods are you talking about? There's still more I plan 
to remove, although that's not my highest priority right now. I intend 
to remove absolutely everything that isn't necessary for starting and 
extending the system. I think some of the reflective support will be 
needed for that (e.g., access to method dictionaries), but much of it 
will not and can be put into loadable modules. The biggest thing I have 
yet to remove is not part of the reflection support (it's the filesystem 

	Anyway, no, I don't think it's a good strategy to completely remove 
reflection. I suspect that any deployed system that does something 
useful will be bigger than the official Spoon release core, even though 
that core will have some reflective capabilty. For one thing, the 
reflective capability that Spoon has allows it to swap out methods that 
any deployed system is going to need (e.g., the methods in True and 
False). CompiledMethods take up about a third of object memory in the 
Spoon object memory currently, so this is a big deal. Of course, this is 
mostly a trick to get the object memory snapshot very small as a network 
payload, even though the execution memory footprint will expand almost 
immediately after startup.

	I think Matthew's comments with regard to security are apropos as well.

	As for how much space might be gained by completely removing reflection 
support, evaluate Apprentice>>printSpaceAnalysis in the working system 
(via proxy from the control system), and muse over the output (e.g., ).

	What constraint are you trying to satisfy?



Craig Latta
improvisational musical informaticist
Smalltalkers do: [:it | All with: Class, (And love: it)]

More information about the Spoon mailing list