Hi eliot
Good question. Let's be clear there are two issues here. One, that shouldn't be in doubt, is that Pharo should use the simple mirror primitives I provided that are already in the VM asap both to provide low level inspectors for proxies and to make the debugger/execution simulator correct. Note that process termination, where a high-priority process terminates a lower one, and end up invoking the execution simulation machinery in getting to a point where unwind blocks can be executed, so the correctness issue can bite in the base system, not just when debugging.
The other issue is your question, should there be a proper set of mirror objects as described by Gilad Bracha. The rationale for proper mirrors is security; to avoid making dangerous primitives like instVarAt: and object:instVarAt: (not to mention allInstances, allObjects, class itself, etc etc) generally available so people can write secure code. This is a great rationale, and makes sense, but the current system is a /long/ way away from that. A truly secure system (meaning a single Smalltalk system which could allow untrusted Smalltalk scripts to run within it and not provide these scripts with the ability to break (into) code in the system) would require much more work than merely providing proper mirrors. The whole system of object access, method access, class manipulation needs to be implemented in a secure manner. That's a great long term project, but just adding mirrors is very far from enough.
Our experience at Cadence where we have used the newspeak mirror system in a non secure squeak host, is that mirrors introduce a lot of complexity and performance overhead and so we've been eliminating their use. Our application provides an SOC domain model that used to be manipulated by mirrors, but we're phasing that out because it costs so much in performance.
So my considered opinion is that we should not add proper mirrors to current Pharo, because we will pay the performance and complexity penalties but not get the security reward. Instead, there should be research projects on small simple systems that attempt to architect a usable secure Smalltalk environment, and when that architecture demonstrates its viability to port the architecture into Pharo. I think that's years away. Interesting. I have two questions: - what is the complexity you mentioned? To have an hierarchy of mirrors and calling the right now instead of a method?
- for the speed cost: What was it exactly? Creating a mirror and sending a message that will then apply the primitive to the object? I imagine that they are some scenarios - like manipulating a remote object or a different space where the cost should be small compared to other operations At cadence what were the use of mirrors? Stef