[799] in Coldmud discussion meeting

Re: Consider: native methods question

daemon@ATHENA.MIT.EDU (Sat Sep 9 15:27:04 1995 )

Date: Sat, 9 Sep 1995 15:23:51 -0400 (EDT)
From: James C Deikun <jcdst10+@pitt.edu>
To: 869683 Gillespie Brandon James <brandon@clarkston.declab.usu.edu>
Cc: coldstuff@MIT.EDU
In-Reply-To: <9509080842.AA09428@clarkston.declab.usu.edu>



On Fri, 8 Sep 1995, 869683 Gillespie Brandon James wrote:

> Native methods are simply functions bound on an object in the same means
> as a method, and which do not exist in the opcode table.
> 
> I'm considering two implementations:
> 
>   #1: Add them to the methods list, hooking into the native code rather than
>       the pcode.  The disadvantage of this lies in it can be awkward.

Awkward?  How?

>   #2: adding a new operator which is a native method operator, for now let
>       us pretend this is '&', so to call a native method you would execute
>       (from the object which has them hashed) it with:
> 
>           &function(..).
> 
>       This would give you more configurability, in that you could more
>       easilly create wrappers.  For instance, consider the string functions,
>       if you wanted to add 'fill', you would:

[deletia]

Why would this be more configurable?  You could achieve the same thing by 
binding a private method to the native code and wrapping that.  In 
addition, you wouldn't need to add a whole other hashtable, and it would 
be much more transparent to move the implementation of a method back and 
forth between native and p-code.

--
James "going native" Deikun