realbasic-plugins
[Top] [All Lists]

Re: [REQUEST] dynamic access

To: REALbasic Plugins <realbasic-plugins at lists dot realsoftware dot com>
Subject: Re: [REQUEST] dynamic access
From: "Joseph J. Strout" <joe at realsoftware dot com>
Date: Sun, 23 May 2004 20:41:44 -0500
Delivered-to: realbasic-plugins at lists dot realsoftware dot com
List-help: <mailto:realbasic-plugins-request@lists.realsoftware.com?subject=help>
List-id: REALbasic Plugins <realbasic-plugins.lists.realsoftware.com>
List-post: <mailto:realbasic-plugins@lists.realsoftware.com>
References: <BCD6FD05 dot 1BC19%sunshine at public dot kherson dot ua>
At 1:14 AM +0300 5/24/04, Ruslan Zasukhin wrote:

1) Joe, as Bjorn have point have have TRY and get practical result that
        dynamic access API is much slower than (I assume) access to methods
        by direct pointers.

    does this wonder you?
    or does this sounds like something wrong?

Yes. Obviously a direct call through a pre-located pointer is faster than a look-up, but it shouldn't be very much slower. And the look-up is necessary for reasons that I hope are clear from the thread started by Alfred. Of course this is not *always* true: if you're going to be calling the same method multiple times on the same object, then it's perfectly valid to look up the function pointer just once and call it many times. But whenever you might be dealing with a different object, possibly of a different subtype, than the last time you looked up the function, you need to look it up again.

2) Joe, you say that Alfred's hack is wrong. It can not work with
subclasses. I can easy see why it will not work.
    (although I have not understand, it seems Alfred have told
    that he have test and it still works.
    may be exist some side-effect which make that hack safe?
    and you do not see that side effect?
    please clarify this.

I'm sorry, I don't quite understand what you're asking here. But let me try to summarize. What Alfred suggested was not really a hack, just a dangerous optimization: caching the function pointer across objects. The problem is that different objects your code sees may actually be different subclasses, and so they might have different function pointers for the same method. If you cache the first one you see, you can end up calling the wrong method later.

What's especially dangerous about this problem is that the bug will only rarely cause a problem -- you are likely to not notice anything wrong at first, and then when your app starts blowing up six months later, have no idea why.

3) you say that you have reject idea with OFFSET to property.
    okay.

Yes, but again, if you find that setting or getting properties is too slow for your purposes, you should file a feature request and we'll see what we can do.

4) I want suggest you next.

    we all know that in C++ exists the same problem:
            pointer on function of a class.

    How it was resolved?
    by special kind of function pointer
(class::* pfoo)();

    such pointer CORRECTLY work with methods of subclasses.
    This is because it is NOT direct pointer like C-language pointer,
    but it is indirect and take into account virtual table of a object.

True. We can't directly use this mechanism with RB objects, but what's going on under the hood is somewhat similar. Yes, there is still a name look-up involved but that can be quite fast (it needn't involve a sequential search).

5) I wonder. REALbasic language have classes, virtual methods (always).
    does it have on RB language level abstraction of
        pointer to function?

Not really -- there is an AddressOf operator which can be used with declares, but it's quite limited in the current language model.

Best,
- Joe

--
,------------------------------------------------------------------.
|    Joseph J. Strout           REAL Software, Inc.                |
|    joe at realsoftware dot com       http://www.realsoftware.com        |
`------------------------------------------------------------------'
_______________________________________________
Unsubscribe or switch delivery mode:
<http://support.realsoftware.com/listmanager/>

Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>

<Prev in Thread] Current Thread [Next in Thread>