[Kde-bindings] Ruby applet dataEngine service operation call

[Arno Rehn]

Hi,

we already know this problem (KPluginFactoy::create() has it as well) and 
currently only have a workaround, which consists of special-casing the 
affected method. This is obviously not the ideal solution.

So what we really want is the following:
For objects that we create ourselves in the bindings language, i.e we 
explicitly call a constructor, we most probably always want to call the native 
implemention of a virtual method (i.e. through a super.foo() call). If we 
subclassed the class in the bindings language, the bindings language's own 
dynamic dispatch will kick in and do the work for us.

If an object is returned by some method and we know that it was _not_ created 
in the bindings language, we want dynamic dispatch to do its work.

Eventually the problem boils down to having to know whether a object is a 
smoke-subclass or just the 'original' class.
I still don't have a solution for this, so suggestions are welcome :)

On Monday 14 December 2009 14:43:18 Richard Dale wrote:
> On Sat, Dec 12, 2009 at 3:58 PM, Cédric <kde at xfou.com> wrote:
> > Hi richard,
> >
> > Do you think this is corrected now and if it is in which release will it
> > be available ?
> 
> No, i'm afraid the code generated by the new smoke bindings generator
> is the same as the old one:
> 
>     void x_12(Smoke::Stack x) {
>         // virtual Plasma::Service* serviceForSource(const QString&)
>         Plasma::Service* xret =
> this->Plasma::DataEngine::serviceForSource(*(const
> QString*)x[1].s_class);
>         x[0].s_class = (void*)xret;
>     }
> 
> It is difficult to allow virtual methods to be overriden in a bindings
> language, at the same time as allowing dynamic despatch for virtual
> methods on unknown classes. I'll cc this mail to kde-bindings at kde.org
> and maybe we can discuss it there.
Yep, kde-bindings seems like a better place to discuss this. ;)
 
> >> On Tue, Aug 18, 2009 at 2:59 PM, Richard Dale <richard.j.dale at gmail.com>
> >>
> >> wrote:
> >>> On Tue, Aug 18, 2009 at 1:45 PM, Cédric<kde at xfou.com> wrote:
> >>> > Thanks Richard,
> >>> >
> >>> > That seems to be the problem.
> >>> > What I was telling in my earlier mail is that the javascript binding
> >>> > seems
> >>> > to have a similar problem with plasmoid.dataEngine("engine
> >>> > name").serviceForSource("source name") and maybe they solved it by
> >>> > implementing the service function: plasmoid.service("engine name",
> >>> > "source
> >>> > name") (and method Plasma::Applet#service is not implemented in ruby
> >>> > ) .
> >>>
> >>> I found the problem. It is a bug in how the smoke library works with
> >>> overriden virtual methods in classes that are don't have bindings
> >>> generated for them. In this case the 'TasksEngine' class isn't part of
> >>> the bindings, and when the serviceForSource() method is called on the
> >>> DataEngine, the code to invoke it looks like this:
> >>>
> >>>    void x_10(Smoke::Stack x) {
> >>>        // serviceForSource(const QString&)
> >>>        Plasma::Service* xret =
> >>> this->Plasma::DataEngine::serviceForSource(*(const QString
> >>> *)x[1].s_voidp);
> >>>        x[0].s_class = (void*)xret;
> >>>    }
> >>>
> >>> When it should probably look like this, and invoke the method in the
> >>> TasksEngine class:
> >>>
> >>>    void x_10(Smoke::Stack x) {
> >>>        // serviceForSource(const QString&)
> >>>        Plasma::Service* xret = this->serviceForSource(*(const QString
> >>> *)x[1].s_voidp);
> >>>        x[0].s_class = (void*)xret;
> >>>    }
> >>>
> >>> Arno Rehn has just written a new smoke library bindings generator, and
> >>> I think we need to discuss this issue and see if we can fix it in that
> >>> tool.
> >>>
> >>> -- Richard

-- 
Arno Rehn
arno at arnorehn.de