Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote:
Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov < dionisiydk@gmail.com dionisiydk@gmail.com> wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < marianopeck@gmail.com marianopeck@gmail.com>:
As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed.
If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
2016-02-15 19:34 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote:
Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Hello,
The #class primitive bytecode is not used in Pharo to avoid this kind of problem.
It is indeed possible to add a setting in Opal compiler not to compile #== using the inlined selector to avoid issues there too. However, even in proxies, it may make sense to have this inlined selector.
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov < dionisiydk@gmail.com dionisiydk@gmail.com> wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < marianopeck@gmail.commarianopeck@gmail.com>:
As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed.
If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
-- _,,,^..^,,,_ best, Eliot
On Mon, Feb 15, 2016 at 4:46 PM, Clément Bera bera.clement@gmail.com wrote:
2016-02-15 19:34 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote:
Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Hello,
The #class primitive bytecode is not used in Pharo to avoid this kind of problem.
It is indeed possible to add a setting in Opal compiler not to compile #== using the inlined selector to avoid issues there too. However, even in proxies, it may make sense to have this inlined selector.
When I made Ghost, Pharo still using the inlined version of #class. So when loading Ghost I used to hack on Opal to avoid optimizing #class. At that time, I did a bench and it showed me that remove the optimization had almost none penalization at all. And in fact, in future Pharo released this ended up being removed.
Cheers,
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov < dionisiydk@gmail.com dionisiydk@gmail.com> wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < marianopeck@gmail.commarianopeck@gmail.com>:
As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed.
If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
-- _,,,^..^,,,_ best, Eliot
2016-02-15 20:49 GMT+01:00 Mariano Martinez Peck marianopeck@gmail.com:
On Mon, Feb 15, 2016 at 4:46 PM, Clément Bera bera.clement@gmail.com wrote:
2016-02-15 19:34 GMT+01:00 Eliot Miranda eliot.miranda@gmail.com:
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote:
Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Hello,
The #class primitive bytecode is not used in Pharo to avoid this kind of problem.
It is indeed possible to add a setting in Opal compiler not to compile #== using the inlined selector to avoid issues there too. However, even in proxies, it may make sense to have this inlined selector.
When I made Ghost, Pharo still using the inlined version of #class. So when loading Ghost I used to hack on Opal to avoid optimizing #class. At that time, I did a bench and it showed me that remove the optimization had almost none penalization at all. And in fact, in future Pharo released this ended up being removed.
Cheers,
Yeah I agree, the class inlined selector doesn't really make sense any more. It's good that it has been removed, so that people doing framework like ghost won't have to worry about it in the future.
On the other hand, #== still makes sense as it it used to make thread safe code. Maybe in the future all the thread safe use cases of #== could be replaced by things such as #valueUnpreemptively and the #== optimization will not be removed.
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov < dionisiydk@gmail.com dionisiydk@gmail.com> wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < marianopeck@gmail.commarianopeck@gmail.com>:
As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed.
If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
-- _,,,^..^,,,_ best, Eliot
-- Mariano http://marianopeck.wordpress.com
In pharo 60 we will revisit and shrink protoObject.
Stef
Le 15/2/16 19:34, Eliot Miranda a écrit :
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo <stepharo@free.fr mailto:stepharo@free.fr> wrote:
Hi eliot I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Stef Le 15/2/16 16:06, Eliot Miranda a écrit :Hi Denis, On Feb 15, 2016, at 6:53 AM, Denis Kudriashov <dionisiydk@gmail.com <mailto:dionisiydk@gmail.com>> wrote:2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck <marianopeck@gmail.com <mailto:marianopeck@gmail.com>>: As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed. If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work. Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.-- _,,,^..^,,,_ best, Eliot
Do we really need ProtoObject?
For clever proxies implementation it is not needed and in some cases it can't be reused. In Ghost we can specify concrete meta level with specific set of known messages. It is based on composition (not inheritance).
So if we don't need ProtoObject for proxies for what purpose we need it?
2016-03-24 7:43 GMT+01:00 stepharo stepharo@free.fr:
In pharo 60 we will revisit and shrink protoObject.
Stef
Le 15/2/16 19:34, Eliot Miranda a écrit :
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote:
Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck < marianopeck@gmail.commarianopeck@gmail.com>:
As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed.
If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
-- _,,,^..^,,,_ best, Eliot
Hi Denis,
On Mar 24, 2016, at 2:22 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
Do we really need ProtoObject?
For clever proxies implementation it is not needed and in some cases it can't be reused. In Ghost we can specify concrete meta level with specific set of known messages. It is based on composition (not inheritance).
So if we don't need ProtoObject for proxies for what purpose we need it?
It's there to avoid crashes when people implement proxy classes and Instantiate before remembering to implement doesNotUnderstand: (a recursive doesNotUnderstand: causes the VM to exit). Also, until the debugger uses mirror primitives ProtoObject is necessary to provide all the support that the execution simulation machinery shouldn't be using ;-).
But I think you're right; if the debugger uses mirrors and the class builder ensures there's always a workable doesNotUnderstand: then one can inherit from nil directly.
2016-03-24 7:43 GMT+01:00 stepharo stepharo@free.fr:
In pharo 60 we will revisit and shrink protoObject.
Stef
Le 15/2/16 19:34, Eliot Miranda a écrit :
Hi Stef,
On Mon, Feb 15, 2016 at 8:18 AM, stepharo stepharo@free.fr wrote: Hi eliot
I think that the difference is really what guillermo explained. With DNU you can only trapped methods that are not defined while if you want to implement true proxy you do not want holes. I think that also with DNU proxy there were some limits realyed to classe but I do not remember.
As far as the VM goes, there is /one/ minor issue with special selector #== and #class (*). But the real issue is that ProtoObject implements far too much protocol. If one creates a class that inherits from nil all it needs to do is implement doersNotUnderstand: and it will catch every message (*). For this to work the debugger and basic inspectors must use the mirror primitives otherwise there will be infinite recursion of MNUs.
Now the issue with special selector #== and #class is that these bytecodes are specified as no lookup. So if one uses bytecodes 182 (#==) or 199 (#class) these operate without sending messages and will compare the object or answer the object's class without sending #doesNotUnderstand:.
In the VW VM I added a flag so one could turn this behaviour off, and that's certainly easy to do in our VM. Another approach is to have the bytecode compiler not send these.
But given our VM it is certainly possible to use doesNotUnderstand: proxies, using a much slimmer class than ProtoObject. In fact a good project would be to try and shrink ProtoObject until it provides the minimum, which would be a #doesNotUnderstand: method that raises an error that reminds the programmer that they need to implement their own doesNotUnderstand: handler in subclasses of ProtoObject.
Stef
Le 15/2/16 16:06, Eliot Miranda a écrit :
Hi Denis,
On Feb 15, 2016, at 6:53 AM, Denis Kudriashov dionisiydk@gmail.com wrote:
2016-02-15 15:32 GMT+01:00 Mariano Martinez Peck marianopeck@gmail.com: > As far as I can remember (this was about 4 years ago) The use of #cannotInterpret: was the only way to be able to intercept everything without breaking the system. Subclassing from ProtoObject make your proxy to understand some messages. Subclassing from nil was technically possible, but I found out the system would simply crash as it didn't know at all how to handle other subclasses of nil. Even with the debugging support I added as you can read in the paper. Maybe things have changed. > > If subclassing from nil does not break the system and you can still inspect, debug proxies, then sure, you can give a try to Ghost using #dnu rather than #cannotInterpret:. In fact, I would like to have a dnu-based approeach that is as reliable as it was #cannotInterpret: in the sense of how much I can intercept. With #cannotInterpret I could trap EVERYTHING (everything but #==) and then decide what to do. Subclassing from nil would get you there too if you make it work.
Actually I already implemented it many yeas ago for Mocketry. But subclassing from nil works correctly only in VW. I got problems when porting it to Squeak (at that time). Now I want to give DNU another chance. It will simplify logic very much. It will remove strange hierarchy of proxies which is needed for trick but raises many questions.
There is no reason in principle why Squeak/Pharo should not be able to use MNU proxies in the same way as VW. The key is to use the mirror primitives in basic inspectors that are used to inspect the proxies and in the debugger to simulate code. Without the mirror primitives many sends to a proxy are likely to create an infinite recursion. As yet we don't have a robust low space handler that catches infinite recursion so debugging can be frustrating. But we can work on this. IMO the MNU approach is to be preferred.
-- _,,,^..^,,,_ best, Eliot
It's there to avoid crashes when people implement proxy classes and Instantiate before remembering to implement doesNotUnderstand: (a recursive doesNotUnderstand: causes the VM to exit).
Strange. The VM knows plenty of objects that could arguably understand a message such as
object: anObject doesNotUnderstand: aMessage
Andres.
Hi Andres,
On Thu, Mar 24, 2016 at 11:20 PM, Andres Valloud < avalloud@smalltalk.comcastbiz.net> wrote:
It's there to avoid crashes when people implement proxy classes and
Instantiate before remembering to implement doesNotUnderstand: (a recursive doesNotUnderstand: causes the VM to exit).
Strange. The VM knows plenty of objects that could arguably understand a message such as
object: anObject doesNotUnderstand: aMessage
What's to stop someone deleting, say, Context>>object:doesNotUnderstand: ? At some point there has to be a message handler. Why bother complicating things by allowing there to be no doesNotUnderstand: ?
_,,,^..^,,,_ best, Eliot
On 3/25/16 18:53 , Eliot Miranda wrote:
Hi Andres,
On Thu, Mar 24, 2016 at 11:20 PM, Andres Valloud <avalloud@smalltalk.comcastbiz.net mailto:avalloud@smalltalk.comcastbiz.net> wrote:
It's there to avoid crashes when people implement proxy classes and Instantiate before remembering to implement doesNotUnderstand: (a recursive doesNotUnderstand: causes the VM to exit). Strange. The VM knows plenty of objects that could arguably understand a message such as object: anObject doesNotUnderstand: aMessageWhat's to stop someone deleting, say, Context>>object:doesNotUnderstand: ? At some point there has to be a message handler. Why bother complicating things by allowing there to be no doesNotUnderstand: ?
To me, the case of omitting a method in a new subclass of nil seems different enough from the case of deleting a method from Context to warrant a different outcome. We can already see that omission of doesNotUnderstand: has already led to the creation of classes such as ProtoObject, i.e. extra complexity.
Andres.
vm-dev@lists.squeakfoundation.org
-
Andres Valloud -
Clément Bera -
Denis Kudriashov -
Eliot Miranda -
Mariano Martinez Peck -
stepharo