Re: How am I supposed to use yaci library?(Yet Another Class Implementation)

[Andrew Starks <andrew.starks@...>]

On Wednesday, February 26, 2014, Journeyer J. Joh <oosaprogrammer@gmail.com> wrote:

Hi Andrew Starks

Virtual function and non virtual function has important difference.

If a function is not a virtual and exist in upper and lower layer of inheritance hierarchy, user of the object can select which function to call. The user can call one in the upper layer or the user can call the other in the lower layer.

But when it comes to virtual function user cannot select which to call. The one at the bottom layer overrides the ones in the upper layers. So user can only call the bottom one.

I C++ changing the view of the object selects. This means type casting of the object.

Many lua OO libraries are all or nothing for virtual function. This means they treat methods always virtual or always non-virtual. But YACI is different. With YACI, I can set a certain function virtual or non-virtual. It gives me power to configure a class' method.

But it seems that YACI has some bugs here. 

https://github.com/jpatte/yaci.lua/issues/3

I filed a bug report.

For this bug, I am not sure whether YACI deserves to be trustworthy or not.

Sincerely

Journeyer

----------------------------------------
Journeyer J. Joh
o o s a p r o g r a m m e r
a t
g m a i l  d o t  c o m
----------------------------------------

2014-02-26 17:15 GMT+09:00 steve donovan <steve.j.donovan@gmail.com>:

On Wed, Feb 26, 2014 at 9:50 AM, Andrew Starks <andrew.starks@trms.com> wrote:
> I think that I don't understand "virtual functions" in this context.
> My understanding was that they are functions that can be redefined by
> classes that are inheriting from the base class that declared it.

Yes, that's exactly what they are; the object carries references to
functions which are resolved at call time (in Lua by table lookup, in
C++ by VMT slot lookup).  The key point is that indirection is
involved.

"virtual method"  is really not a concept that makes sense in dynamic languages.

This was helpful. Now I see that it is the ability to choose between non-virtual and virtual, based on how it is accessed, as the goal. 

This is related, in a small way, to my desire to figure out a clean way to say, "this *as* that", especially when I want to support multiple argument "types" in a single function. In order to do this, I think that a complete type system is needed, but there may also be an elegant solution that I haven't thought of yet.

Not doing that, has been the solution that has worked best, so far. :)

-Andrew