Exactly, this applies to ALL objects, not just view. Since view is object built, then it follows the same rules as any other object...
I think I've understood what happens and it seems as if they store a "vector" list. This is an array of offsets from the base object address which in turn point to other areas in memory. each position is fixed in order to make this system speedy. Especially since most compilers/assemblers have instructions to calculate offset resolution in one opcode (usually one machine instruction). The amiga's library system is built almost exactly like this. It would be consistent with Carl, and why change something that works well and fast!? In rebol, I guess they build this vector list the first time the object is defined and then just link to it everytime. Then, when a new object is cloned and the template changes, I guess they just allocate a new vector list with new fields APPENDED... this would make any cloned objects completely safe to use with "parent" objects this also looks like the Amiga library system which had two modes... the first one returned the same data segement everytime and thus all applications SHARED the same data, and another one where every call to open library returned a NEW data segment but with the same vector jumplist... this second mode looks almost like a direct translation to rebol objects... AS usual, these are just my observations... not explicit RT answers... hope this makes sense to all... -MAx ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, November 13, 2001 5:49 AM Subject: [REBOL] Re: Strange behaviour in Make object? > RE: [REBOL] Re: Strange behaviour in Make object? > > I think RT handles this somewhat lazy. > when accessing objects from c, its easier and faster to > do this by index instead of searching the object for name > (i think). > > with 'port! they have a clean solution. > 'port! is like an object, but c can check. > if its a port!, it has the right order. > if no 'port!, its rejected. > so we should have face! and that too, > instead of allowing objects there. > > but i expect adding new datatypes! is somewhat expensive > in current implementation, and the only drawback > today is telling "you have to use [make face]. thats by design". > instead of checking it. > so some guis have to figure around instead of getting > a helpfull clean message. > there was > > and now i give word to the experts: > > [REBOL] Re: view bug (with feel attribute) > > [EMAIL PROTECTED] wrote: > > > > On Tue, Oct 23, 2001 at 01:07:53PM -0400, Media wrote: > > > Hi again, > > > > > > > > > maybe some of you are aware... > > > > > > I just discovered that if you create your feel object for a face and include > > > the functions in the wrong order, your event handling will be PURE CHAOS!!! > > > > Sure, that is expected. Any time you create an instance of an object > > with a predefined structure you MUST use the template object. You cannot > > roll your own object from scratch and expect the result to be compatible > > with the template. > > > > This means use make face [...], make feel [...] etc., not make object! [...]. > > > > -- > > Holger Kruse > > [EMAIL PROTECTED] > > > > -Volker > > [EMAIL PROTECTED] wrote: > > > > > > Brett Handley said: > > > > > Hi James, > > > > > > I can't shed any light on it. But I do suggest that rather using MAKE > > > OBJECT! directly you use MAKE FACE > > > so that you are assured of having the correct View fields constructed > > > properly. > > > > > > There is some evidence to suggest that the View engine interfaces with > > these > > > objects in a low level way and order of the fields could be important. > > Much > > > better to follow the convention. > > > > > > Brett. > > > > > > > Yup - was just curious as to why changing the order was causing issues. I > > had a similar problem on another object where a field immediately following > > a pair was causing display errors if it was an integer field eg: > > Obj1: make object! [ > > var1: 0x0 > > var2: 1 > > var3: make get-style 'face [ > > ... > > ] > > ... > > ] > > > > This would also seem to build correctly but on creating a new object with > > make obj1 [] the var3 would be ignored and often weird errors would result - > > I had one case where a pair was being assigned to an object, seemingly from > > nowhere. I swapped the order of 2 custom variables I had defined and was > > surprised to find that it now worked. > > > > Go figure ;-) > > > > > > James > > > > -- > > To unsubscribe from this list, please send an email to > > [EMAIL PROTECTED] with "unsubscribe" in the > > subject, without the quotes. > > > -- > To unsubscribe from this list, please send an email to > [EMAIL PROTECTED] with "unsubscribe" in the > subject, without the quotes. > -- To unsubscribe from this list, please send an email to [EMAIL PROTECTED] with "unsubscribe" in the subject, without the quotes.
