ruby-x/ruby-x.github.io
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

change layout to type

Browse Source
This commit is contained in:
Torsten Ruger
2016-02-25 19:10:56 -08:00
parent ed94806e36
commit 48e4c8a27d
5 changed files with 29 additions and 28 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
_posts/2014-07-17-framing.md
View File

@ -42,7 +42,7 @@ a reference tags the class for when that is known at compile time. If so i can d
inline the get's implementation. If not i could cache, but that's for later.
As a furhter example on this, when one function has two calls on the same object, the layout must only be retrieved once.
ie in the sequences getLayout, determine method, call, the first step can be ommitted for the second call as a layout is
ie in the sequences getType, determine method, call, the first step can be ommitted for the second call as a layout is
constant.
And as a final bonus of all this clarity, i immediately spotted the inconcistency in my own design: The frame i designed
@ -70,7 +70,7 @@ smalltalk (like ruby and...) all objects have a class. But some of the smalltalk
objects. This was supposed to make things easier and faster. Slots were a bit like instance variables, but there were no
classes to rule them.
Now in ruby, any object can have any variables anyway, but they incur a dynamic lookup. Layouts on the other hand are like
slots, and keeping each Layout constant (while an object can change layouts) makes it possible to have completely
Now in ruby, any object can have any variables anyway, but they incur a dynamic lookup. Types on the other hand are like
slots, and keeping each Type constant (while an object can change layouts) makes it possible to have completely
dynamic behaviour (smalltalk/ruby) **and** use a slot-like (self) system with constant lookup speed. Admittatley the
constantcy only affects cache hits, but as most systems are not dynamic most of the time, that is almost always.