Re: OBJECTS.FS Question

ragofu64@[EMAIL PROTECTED]
 wrote:

> Further test have shown that this do not work for cl***** implementing
> interfaces. I'm working on that to find out why.

That is unfortunate.  Let's hope there is a way to do so.  IMHO 
Objects.fs *require* interfaces so the programmer is not burdened with 
the constraints of which messages can be passed to which objects, i.e., 
having to design the class hierarchy in a specific way.

With the Neon style model all messages can be sent to all objects and 
interfaces are not required (nor do interfaces even exist).  Neon has 
always been compatible with saved images and turnkeys.  I have recently 
implemented message dispatch tables for Neon, let's call it Neon+. 
Neon+ has a constant time for sending late-bound messages and by my 
measurement is clearly faster than Objects.fs in doing so.  Neon+ 
retains all other features of Neon, notably default early binding (no 
extra work required from the programmer), and so is considerably faster 
than Objects.fs.

-Doug


> On 1 mayo, 02:22, Doug Hoffman <no.spam> wrote:
>> ragof...@[EMAIL PROTECTED]
 wrote:
>>> I have found an easy way to make it fully persistant: after all
>>> methods have been defined,
>>>  you have the full size and start address of the virtual table for
>>> each class.
>>> So it is easy to add a word (let's say "persistant") that copies this
>>> table back to
>>> the dictionary,
>>> then patch the last class bookeeping fields and release the memory
>>> from the heap.
>>> This must be done for each class and interface you want to persist. It
>>> works,
>>> at least for me.
>> Thank you for that.  I wonder if persistant could simply be made part
of
>> the end-methods definition?  This would follow the rule of Minimum
>> Astonishment when saving an image or creating a turnkey.
>>
>> -Doug
>