2015-04-06 10:38:11 +02:00
|
|
|
|
2015-04-08 19:24:50 +02:00
|
|
|
# A Frame is set up by functions that use local variables or temporary variables
|
|
|
|
# in fact temporary variables are local variables named by the system
|
|
|
|
|
2015-05-10 16:12:43 +02:00
|
|
|
# It allows for access to those variables basically
|
|
|
|
|
|
|
|
# A Message and a Frame make up the two sides of message passing:
|
2015-10-23 13:22:55 +02:00
|
|
|
# A Message (see details there) is created by the caller and control is transferred
|
2015-05-10 16:12:43 +02:00
|
|
|
# A Frame is created by the receiver
|
2015-07-01 18:27:18 +02:00
|
|
|
# PS: it turns out that both messages and frames are created at compile, not run-time, and
|
2016-02-25 21:03:11 +01:00
|
|
|
# just constantly reused. Each message has a frame object ready and is also linked
|
2015-07-01 18:27:18 +02:00
|
|
|
# to the next message.
|
2015-10-23 13:22:55 +02:00
|
|
|
# The better way to say above is that a message is *used* by the caller, and a frame by the callee.
|
2015-05-10 16:12:43 +02:00
|
|
|
|
2016-02-25 21:03:11 +01:00
|
|
|
# Also at runtime Messages and Frames remain completely "normal" objects.
|
|
|
|
# Ie they have have type and instances and so on.*
|
2015-05-10 16:12:43 +02:00
|
|
|
# Which resolves the dichotomy of objects on the stack or heap. Sama sama.
|
2016-02-25 21:03:11 +01:00
|
|
|
#
|
|
|
|
# *Alas the type for each call instance is unique.
|
|
|
|
#
|
2015-05-11 17:55:49 +02:00
|
|
|
module Parfait
|
2015-06-28 21:02:07 +02:00
|
|
|
class Frame < Object
|
2015-07-30 18:18:41 +02:00
|
|
|
attribute :next_frame
|
|
|
|
|
2015-10-27 15:04:36 +01:00
|
|
|
include Indexed
|
2016-02-25 20:50:10 +01:00
|
|
|
self.offset(2) # 1 == the next_frame attributes above + type. (indexed_length gets added)
|
2015-10-22 10:02:46 +02:00
|
|
|
|
2015-05-10 16:12:43 +02:00
|
|
|
end
|
2015-04-06 10:38:11 +02:00
|
|
|
end
|