[DGD] Overriding kfuns

[Raymond Jennings]

Basically, from the POV of a calling program, it has a static inheritance
graph that doesn't change.  Until it's recompiled, it has hard references
on its direct inherits (which cascade as needed upward until it hits the
kfun layer).

On Wed, Feb 8, 2017 at 2:34 PM, Raymond Jennings <shentino at gmail.com> wrote:

> Also, the program/object that is actually overriding the kfun in question
> is an ordinary inheritable in the calling program's inheritance graph.
>
> Since you can't recompile an inheritable in place, the calling program
> wont' even know if it's still overridden or not unless it itself is
> recompiled to possibly use an updated version of the inheritable...and in
> the process generating new bytecode anyway.
>
> This also applies to the auto object.
>
> Don't forget basically that you could wind up with two issues of the same
> inheritable, each using different source, one of which may override a given
> kfun and one of which may not.  If you're in the middle of a global
> rebuild/recompile, you may even have BOTH issues active at the same time ;).
>
>
> On Wed, Feb 8, 2017 at 2:06 PM, Blain <blain20 at gmail.com> wrote:
>
>> And thanks for the response. :)
>>
>> On Feb 8, 2017 4:05 PM, "Blain" <blain20 at gmail.com> wrote:
>>
>> > Ok, that's a difference from what I'm used to. Good to know.
>> >
>> > On Feb 8, 2017 4:04 PM, <bart at wotf.org> wrote:
>> >
>> >> If explode() wasn't a kfun, you'd get an undefined function error
>> >> according to
>> >> the rules of DGD's lpc dialect. When compiling the code for the
>> member()
>> >> lfun,
>> >> it simply doesn't know yet about the later explode() lfun, unless you
>> >> provide
>> >> a prototype.
>> >>
>> >> Now, explode is a kfun, so when it gets referenced in member(), dgd
>> still
>> >> doesn't know about your lfun, but it does know about the kfun, so you
>> get
>> >> no
>> >> error.
>> >>
>> >> Now, the bytecode to call an lfun is different from the bytecode to
>> call a
>> >> kfun, and member() has been compiled to use bytecode for calling the
>> kfun
>> >> so
>> >> it will never look at your lfun at all.
>> >>
>> >> As an aside, functions defined in the auto object have similar
>> properties
>> >> (and
>> >> iirc calling an afun also uses different bytecode)
>> >>
>> >> So for all I can tell, its a combination of the language rules and the
>> >> design
>> >> of dgd.
>> >>
>> >> Bart.
>> >>
>> >> On Wed, 8 Feb 2017 14:36:47 -0600, Blain wrote
>> >> > Quick question.
>> >> >
>> >> > lfun: member()
>> >> > lfun: explode()
>> >> >
>> >> > My lfun member() was using the kfun explode() instead of my lfun
>> >> > explode() further down in the object until I added a prototype for
>> >> > explode() at the top of the file.  Is this by design?
>> >> ____________________________________________
>> >> > https://mail.dworkin.nl/mailman/listinfo/dgd
>> >>
>> >>
>> >> --
>> >> http://www.flickr.com/photos/mrobjective/
>> >> http://www.om-d.org/
>> >>
>> >> ____________________________________________
>> >> https://mail.dworkin.nl/mailman/listinfo/dgd
>> >
>> >
>> ____________________________________________
>> https://mail.dworkin.nl/mailman/listinfo/dgd
>>
>
>