Tell whether a primitive subprogram was overridden

Tell whether a primitive subprogram was overridden

[Victor Porton]

Is it possible to determine whether for a given object of type T'Class a 
primitive subprogram F was overridden (not the same as for type T)?

I would like this check for efficiency reasons, not to pass it to a callback 
if the default "null" operation was not overridden.

-- 
Victor Porton - http://portonvictor.org

Re: Tell whether a primitive subprogram was overridden

[Adam Beneschan]

On Monday, August 18, 2014 4:41:24 PM UTC-7, Victor Porton wrote:
> Is it possible to determine whether for a given object of type T'Class a 
> primitive subprogram F was overridden (not the same as for type T)?
> 
> I would like this check for efficiency reasons, not to pass it to a callback 
> if the default "null" operation was not overridden.

No, Ada doesn't provide a mechanism for this.  I don't know of a language that does, although in some languages you might be able to use "reflection" to squeeze the information out, but with some difficulty.

The best solution that I can think of is to add a function to T:

    function F_Does_Something_Useful (Obj : T) return boolean;

This would be False for T, but for any derived type where you override F, you'd also override this function to make it return True.  

                            -- Adam

Re: Tell whether a primitive subprogram was overridden

[Victor Porton]

Adam Beneschan wrote:

> On Monday, August 18, 2014 4:41:24 PM UTC-7, Victor Porton wrote:
>> Is it possible to determine whether for a given object of type T'Class a
>> primitive subprogram F was overridden (not the same as for type T)?
>> 
>> I would like this check for efficiency reasons, not to pass it to a
>> callback if the default "null" operation was not overridden.
> 
> No, Ada doesn't provide a mechanism for this.  I don't know of a language
> that does, although in some languages you might be able to use
> "reflection" to squeeze the information out, but with some difficulty.
> 
> The best solution that I can think of is to add a function to T:
> 
>     function F_Does_Something_Useful (Obj : T) return boolean;
> 
> This would be False for T, but for any derived type where you override F,
> you'd also override this function to make it return True.

No, I won't add this obscure function F_Does_Something_Useful only to 
increase the speed for a tiny bit.

-- 
Victor Porton - http://portonvictor.org

Re: Tell whether a primitive subprogram was overridden

[Simon Wright]

Victor Porton <porton@narod.ru> writes:

> Adam Beneschan wrote:
>
>> On Monday, August 18, 2014 4:41:24 PM UTC-7, Victor Porton wrote:
>>> Is it possible to determine whether for a given object of type T'Class a
>>> primitive subprogram F was overridden (not the same as for type T)?
>>> 
>>> I would like this check for efficiency reasons, not to pass it to a
>>> callback if the default "null" operation was not overridden.
>> 
>> No, Ada doesn't provide a mechanism for this.  I don't know of a
>> language that does, although in some languages you might be able to
>> use "reflection" to squeeze the information out, but with some
>> difficulty.
>> 
>> The best solution that I can think of is to add a function to T:
>> 
>>     function F_Does_Something_Useful (Obj : T) return boolean;
>> 
>> This would be False for T, but for any derived type where you
>> override F, you'd also override this function to make it return True.
>
> No, I won't add this obscure function F_Does_Something_Useful only to
> increase the speed for a tiny bit.

Then you shouldn't be worrying about efficiency in the first place!
(later on, maybe ...)

Re: Tell whether a primitive subprogram was overridden

[Shark8]

On 18-Aug-14 17:52, Adam Beneschan wrote:
> On Monday, August 18, 2014 4:41:24 PM UTC-7, Victor Porton wrote:
>> Is it possible to determine whether for a given object of type T'Class a
>> primitive subprogram F was overridden (not the same as for type T)?
>>
>> I would like this check for efficiency reasons, not to pass it to a callback
>> if the default "null" operation was not overridden.
>
> No, Ada doesn't provide a mechanism for this.
> I don't know of a language that does, although in some languages you might be
> able to use "reflection" to squeeze the information out, but with some difficulty.
>
> The best solution that I can think of is to add a function to T:
>
>      function F_Does_Something_Useful (Obj : T) return boolean;
>
> This would be False for T, but for any derived type where you override F,
> you'd also override this function to make it return True.
>
>                              -- Adam
>

You *MIGHT* be able to do it w/ LISP; the homoiconic nature and 
first-class functions should combine quite well with the OOP framework 
to allow such a query.

Re: Tell whether a primitive subprogram was overridden

[Dmitry A. Kazakov]

On Tue, 19 Aug 2014 02:41:24 +0300, Victor Porton wrote:

> Is it possible to determine whether for a given object of type T'Class a 
> primitive subprogram F was overridden (not the same as for type T)?

It is always overridden even if inherited. Purely formally, since the type
is different, e.g. S derived from T, then it cannot be the same subprogram.
[Technically it can have some additional trampoline code as well.]

> I would like this check for efficiency reasons, not to pass it to a callback 
> if the default "null" operation was not overridden.

You mean that a check would be more efficient than a dispatching call? I
don't think there would be much difference, except the case when the
subprogram has a long list of additional arguments or computed arguments.
That is usually the case when doing tracing stuff. In that case you could
think of some lazy parameter evaluation schema or upfront checks as Adam
suggested.

You could also split the base type into two or more types adding the
primitive operations up the derivation tree. At the call point you could
check if the descendant is in the subclass that has the operation and call
only if it is. But I think this, apart from being extremely ugly, might be
in fact slower than a honest dispatching call.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Tell whether a primitive subprogram was overridden

[Victor Porton]

Dmitry A. Kazakov wrote:
> On Tue, 19 Aug 2014 02:41:24 +0300, Victor Porton wrote:
> 
>> Is it possible to determine whether for a given object of type T'Class a
>> primitive subprogram F was overridden (not the same as for type T)?
> 
> It is always overridden even if inherited. Purely formally, since the type
> is different, e.g. S derived from T, then it cannot be the same
> subprogram.
> [Technically it can have some additional trampoline code as well.]
> 
>> I would like this check for efficiency reasons, not to pass it to a
>> callback if the default "null" operation was not overridden.
> 
> You mean that a check would be more efficient than a dispatching call? I
> don't think there would be much difference, except the case when the
> subprogram has a long list of additional arguments or computed arguments.
> That is usually the case when doing tracing stuff. In that case you could
> think of some lazy parameter evaluation schema or upfront checks as Adam
> suggested.

No. I haven't described exactly what I do.

I need to register (by calling a C function) a C wrapper around a method of 
my class as a callback subprogram. If my method is null, it is not necessary 
to register it and the C code would not call it.

-- 
Victor Porton - http://portonvictor.org

Re: Tell whether a primitive subprogram was overridden

[Dmitry A. Kazakov]

On Tue, 19 Aug 2014 16:45:54 +0300, Victor Porton wrote:

> Dmitry A. Kazakov wrote:

>> You mean that a check would be more efficient than a dispatching call? I
>> don't think there would be much difference, except the case when the
>> subprogram has a long list of additional arguments or computed arguments.
>> That is usually the case when doing tracing stuff. In that case you could
>> think of some lazy parameter evaluation schema or upfront checks as Adam
>> suggested.
> 
> No. I haven't described exactly what I do.
> 
> I need to register (by calling a C function) a C wrapper around a method of 
> my class as a callback subprogram. If my method is null, it is not necessary 
> to register it and the C code would not call it.

You certainly register it only once. Therefore it is indeed the overhead of
a single dispatching call = a couple of nanoseconds. If you are in this
area you should look at C code as well. It checks if something is
registered. The depending on the choice it does a jump or no jump. Jump is
also a nanosecond of so.

Morale: premature optimization is the root of all evil.

[ And you never know if what you are doing would make the code faster,
until you measure it. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Tell whether a primitive subprogram was overridden

[Victor Porton]

Dmitry A. Kazakov wrote:

> On Tue, 19 Aug 2014 16:45:54 +0300, Victor Porton wrote:
> 
>> Dmitry A. Kazakov wrote:
> 
>>> You mean that a check would be more efficient than a dispatching call? I
>>> don't think there would be much difference, except the case when the
>>> subprogram has a long list of additional arguments or computed
>>> arguments. That is usually the case when doing tracing stuff. In that
>>> case you could think of some lazy parameter evaluation schema or upfront
>>> checks as Adam suggested.
>> 
>> No. I haven't described exactly what I do.
>> 
>> I need to register (by calling a C function) a C wrapper around a method
>> of my class as a callback subprogram. If my method is null, it is not
>> necessary to register it and the C code would not call it.
> 
> You certainly register it only once. Therefore it is indeed the overhead
> of a single dispatching call = a couple of nanoseconds. If you are in this
> area you should look at C code as well. It checks if something is
> registered. The depending on the choice it does a jump or no jump. Jump is
> also a nanosecond of so.

No, I register it either once or zero times.

If it is not registered, the program is a little faster.

-- 
Victor Porton - http://portonvictor.org