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 support).
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., http://netjam.org/spoon/notes/space2.txt ).
What constraint are you trying to satisfy?
thanks,
-C