[Vm-dev] Cog: A question about: setInterruptCheckChain()

[Eliot Miranda]

On Wed, Sep 29, 2010 at 10:22 AM, Andreas Raab <andreas.raab at gmx.de> wrote:

>
> On 9/29/2010 9:36 AM, Eliot Miranda wrote:
>
>>    See the recordMouseEvent() and its friends (sqNextEventPut,
>>    eventBuffer[1024] ...) in sqWin32Window, for better understanding my
>>    point :)
>>
>>
>> Which makes my point well.  These are simply maintaining a queue.  If
>> one has callbacks then the bulk of the Windows event handling system can
>> be lifted up into the image.  This is what Vassili Bykov did in Newspeak
>> above my Alien callbacks.  In Newspeak the Windows MainWndProc is a
>> callback:
>>
>
> Thus losing any level of platform abstraction. A bad trade-off, IMO.
>

The platform abstraction merely moves from the VM to classes in the image.
 But it does mean that one can properly implement Windows event semantics
(things like query quit events) that the queue prevents.  And it means that
the VM gets simpler and complexity is handled by better facilities (in
Smalltalk with its many advantages for creating and maintaining abstractions
with concrete variant implementations).

But you and I have had this discussion a number of times and I take your
point about the VM maintaining a black-box abstraction boundary whereas the
in-image implementation is in theory porous.  As I've said before this
doesn't strike me as that important when Smalltalk has had boundary
violators such as instVarAt:[put:] for ever and they are rarely abused.  If
one were to implement a native GUI event interface in Smalltalk using
callbacks one would have to police the abstraction boundary.  But that's
easily done, and there are other benefits
- the VM, being simpler, gets more longevity since changing the event
interface doesn't imply a VM change
- the system, having native interfaces, can support each platform's
facilities in full instead of providing the lowest common denominator

So IMO it is a good trade-off.

best
Eliot


> Cheers,
>  - Andreas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20100929/792177c7/attachment.htm