[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kjsembed
Subject:    [kjsembed] Planning for a new base binding
From:       "Matt Broadstone" <mbroadst () gmail ! com>
Date:       2006-10-18 2:28:35
Message-ID: 621909c70610171928u1dc1182aof0f6125022098dba () mail ! gmail ! com
[Download RAW message or body]

Hey guys,
     I've been doing a lot of research on replacing our current 3 core
bindings with a single one in order to: a) increase maintainability
and b) overcome some current shortcomings we have in our
implementation (no generic extracts etc).. I'm going to paste a
conversation I had with Maks Orlovich earlier today with his concerns
regarding using boost::any for a general binding class:

[06:27PM] <SadEagle> [mX]: I don't see how a variant class solves anything
[06:27PM] <[mX]> SadEagle: well we move from 3 generic bindings to 1
[06:28PM] <[mX]> and we can maintain type safety, as opposed to void*+typeinfo
[06:28PM] <[mX]> it solves a whole lot
[06:28PM] <SadEagle> sounds untrue.
[06:28PM] <[mX]> how do you figure
[06:29PM] <SadEagle> because if its type-safe, it's not 'any'
[06:29PM] <[mX]> sure it is, you should check out the code
[06:30PM] <SadEagle> may be if boost.org ws actually up :-)
[06:30PM] <[mX]> doh
[06:30PM] <[mX]> well
[06:30PM] <[mX]>
http://boost.cvs.sourceforge.net/boost/boost/boost/any.hpp?revision=1.12&view=markup
[06:31PM] <SadEagle> but you can't guarantee real (static) type safety
with a generic 'any' type. tagged variants that are
          exhaustive, sure.
[06:31PM] <SadEagle> plus most Qt types are uncopyable.
[06:32PM] <[mX]> well generally the Qt types we'll be storing are
going to be pointers
[06:32PM] <[mX]> so we get those for free
[06:33PM] <[mX]> the ones that aren't generally are copyable, and are
generally QVariants
[06:33PM] <[mX]> yes we will have to work with corner cases, but this
solution handles most cases
[06:34PM] <SadEagle> I don't beleive this handles inheritance properly.
[06:35PM] <[mX]> void* surely does not handle inheritance properly, I
don't see how this doesn't, you are effectively
          storing the exact value in the class
[06:35PM] <SadEagle> any_cast just compares type_info structures.
[06:35PM] <[mX]> well yeah the limitation of this is that you need to
know the exact type
[06:35PM] <SadEagle> ...
[06:35PM] <[mX]> luckily we do in autobinding
[06:36PM] <SadEagle> what's the point, again?
[06:37PM] <[mX]> to use a typesafe generic container for types in our bindings
[06:37PM] <SadEagle> not to mention RTTI is pretty risky to play with
unless we switch to RTLD_GLOBAL --- which we prolly
          should.
[06:37PM] <SadEagle> well, the notion of typesafety here is rather
weak, and genericity is questionnable, too.
[06:38PM] <[mX]> its certainly more typesafe than just using void*
[06:38PM] <[mX]> although weak, I'm not sure you could come up with a
"strong" method
[06:38PM] <SadEagle> hmm. I doubt you can store a QRect in this.,
[06:39PM] <[mX]> and its as generic as it needs to be, these bindings
don't change internal values during their lifespan
[06:39PM] <[mX]> well ians plan was basically to provide the copy's
using the qmetatype methods, but just not use qvariant
[06:40PM] <[mX]> as in register all our bound types with qmetatype
[06:40PM] <[mX]> in that scenario qrect could play nicely
[06:43PM] <SadEagle> OK, it can work with QRect, but you're playing
with fire with the SOs then.
[06:43PM] <SadEagle> Since the TI note for types w/o virtuals is not
emitted when they're compiled.
[06:43PM] <SadEagle> So if you cross SO boundaries, casts may start failing...
[06:47PM] <[mX]> well regardless, thats what the experimental branch
is for, its worth a shot because it makes
          maintainability a lot easier for us, not to mention it makes
things a whole lot simpler when trying to autobind
          classes
[06:48PM] <SadEagle> I don't buy that, because I think that stuff is
the easy part.
[06:48PM] <SadEagle> memory management is the hard part.
[06:49PM] <[mX]> well obviously thats going to be difficult, but we're
at a point right know where we can't generically
          extract a Container<whatever type> from js
[06:49PM] <SadEagle> uhm, Container<whatever type> can't be generally
extracted, period.
[06:50PM] <[mX]> actually it can
[06:50PM] <[mX]> we get an array of types from js
[06:50PM] <SadEagle> nope, you can only extract from Container<CompileTimeType>
[06:50PM] <[mX]> and we extract the list and convert it to a QList
[06:51PM] <[mX]> yes thats what I meant
[06:51PM] <SadEagle> ah, that direction, OK, that makes more sense.
[06:52PM] <[mX]> anyway, I just didn't want to get in trouble adding
any to the branch in terms of licenses, so we'll see
          if it helps at all

--
Also, if we are to stay with the current binding situation we need to
devise a way where we can call a generic value() method on all of them
an indiscriminate way as long as you know the type (I _really_ need
this right now to handle extracting KJS::List's into QLists). Ideally
we could have a BaseBinding interface with some templated virtuals,
but as well all know that's not legal in C++ land.

Any ideas are MORE than welcome, this is a constant IQ test ;)

Matt
_______________________________________________
kjsembed mailing list
kjsembed@kde.org
https://mail.kde.org/mailman/listinfo/kjsembed
[prev in list] [next in list] [prev in thread] [next in thread]