Method-chaining and Simple-types as objects

[Daniel B. Faken]

On Wed, 18 May 2005, John (J5) Palmieri wrote:
[snip]
> > * sending messages to simple-types (integers etc.), when they are the 
> > return-value of  a method-call.  (but see below for a more general scheme)
> 
> But what messages would they support?

getting size, splitting, comparing, translation, hashing......

In Squeak the String class has around 200 methods, and this is not 
counting subclasses or superclasses..



> > * combining what would be multiple inter-process calls into a single one.
> 
> Why not just do this in the API of the service?
> 
[snip]
> 
> We throw an error if we can't marshal it to a dbus type.  In this case
> the bignum would have to be explicitly "cast" to a type object or
> converted to a string.  The service should decide what to do with it.
> 
[snip]
> > With the above-mentioned chaining, though, I can do
> >   /pgpinfo->methodCallChain('key', ['factor', 23940])
> > which will return the correct result.
> 
> Why not just /pgpinfo->factor_key(23940)?
>
> >   This will also save a round-trip and possibly bignum-conversions.
> 
> so does the above and it is a lot nicer

Yes, you can of course just design the DBus-exposed API for special cases, 
but this misses the point.
  I want to use the API (i.e. the class definitions) that are *already* 
available through the language, and to do this efficiently.

And yes of course the syntax I gave is very ugly - it could be seriously 
cleaned up, depending on the language (e.g. as a first approximation the
pgpinfo.chain(2).key.factor(23940) example I gave).  See also the bottom 
of this message..

> >   I see much traffic on the DBus list regarding C bindings like GLib.  
> > The content of this posting may not seem as relevant if you are calling 
> > *out* to C.  But, if you are trying to interface languages where 
> > "Everything is an Object" (e.g. Smalltalk), I think some solution of this 
> > nature will be important.
> > 
> 
> Sorry to be over critical of this idea but it does look like solution in
> search of a problem.

Criticism is welcome :).  I am definitely partial to elegant solutions, 
not bloated ones.

A real example application: 
  I now have some bindings working where Python and Smalltalk 
intercommunicate to do 3D rendering, using the native Smalltalk types and 
functions.  E.g. a render method called by the render: method of a Squeak 
TDBusProxy object:
    def render(self, ogl):
        #print("Python TObject: would render with ogl=%s!\n" % ogl)
        sqobj(ogl).glColor3f_with_with(0.5, 0.5, 0.5)
        sqobj(self.myobj).renderCube_scale(ogl, 1.0)

Here 'ogl' is a class representing an OpenGL interface drawing to a 
particular OpenGL context in the Squeak program (well, Croquet actually - 
see opencroquet.org), and 'myobj' refers to the TDBusProxy object in the 
squeak program..

I'm not claiming this is the best way to do 3D rendering or anything - 
just showing what I want to be able to do, without defining interfaces on 
top of those already present.

(note this example doesn't actually use methods on simple types; the 
point is an interface without "surprises")

>  I think well thought out API's is the solution to
> the round trip problem as well as not using DBus for lowlevel
> operations.  Keeping the bindings simple and maintainable is also a huge
> goal that this would complicate.  Really DBus is not "the" technology
> for lack of a better phase.  It is an enabler that enables other
> technologies.  Adding something like this puts rules into DBus that I
> believe should be left to the author of the API being wrapped by DBus.

I don't necessarily disagree.  I'm just interested in discussing how to 
map such higher-level interfaces naturally with DBus as-it-is.
  A basic issue in such an interface is how to send messages to types that 
DBus considers basic.
  The (fairly unattractive, I'll admit) call-chaining I proposed is simply 
a solution to this problem that DOESN'T require changes to DBus or lots of 
layers around it (I did consider many other ways first).

I have never used Glib, so I'm sure I don't understand the point of view 
of people heavily tied into it.  But since DBus already has Python, Ruby, 
etc. bindings I'm guessing there will be some people interested in the 
higher-levels.

regards,
Daniel