"Daniel Wallin" <dalwan01@student.umu.se> writes:
"Daniel Wallin" <dalwan01@student.umu.se> writes:
The type of the type-identifier needs to be known to the library though, so my point is that it can't be a template which the user just specializes. You also need to set the type for the compiled part of the library. Or am I missing something here?
Probably not; I think you have a good point, at least, if we need runtime polymorphism among type id objects or if they need to be manipulated in the compiled part of the library.
typedefs still work, though.
Yeah, a typedef would have been a much better solution. I think the reason we use macro's is because we used const type_info* directly, instead of wrapping it in a class. So we couldn't simply use < and == when comparing the types.
> > This of course causes some problems if we want to > > downcast > > And if you want to support CBD (component based > development, i.e. cross-module conversions), unless > you can somehow get all authors to agree on how to > identify types. Well, I guess they could use > strings and manually supply what > std::type_info::name() does.
It doesn't seem wrong that the authors need to use the same typeid. If you aren't developing a closed system, don't change typeid system.
I was thinking more of id collisions among extensions which don't intend to share types. It becomes less of an issue if people use string ids.
But like I said, if you intend to use your module with other modules; don't change the typeid system.
I'm not talking about changing systems, just the need to ensure unique type IDs for different types across modules.
Yeah I know, what I'm saying is that you will only get problems like that if you change your type_info represantation to something like 'int'. In which case you have changed type id system. This isn't a problem as long as you stick to typeid() and type_info?
Assuming a single compiler and the use of distinct namespaces, no.
Right.
LUABIND_DONT_COPY_STRINGS
What kind of string copying gets disabled?
It causes names to be held by const char* instead of std::string. (class names, function names etc).
Why not always do that?
Hold const char*? Because you can't control their lifetime? :)
You mean that some people want to compute these things dynamically instead of using string literals? Nobody has ever asked me for that. I bet this is one area of configurability that could be dropped.
We actually have one user that uses this feature, I don't know if he actually needs to though. So yeah, it could probably be dropped.
Need to think about this some more. It's no special case in BPL though, it's just another type of instance_holder, correct?
Not only that. It's an issue of where the instance holder gets constructed. In this case it is constructed directly in the storage for the Python object.
Right, that's pretty cool.
Yeah, but I doubt it's saving much, and it leads to much complication (c.f. instance_new and instance_dealloc in libs/python/src/object/class.cpp). If objects are getting created and destroyed a *lot* it could reduce fragmentation and increase locality... but as I said I have big doubts.
Yeah, fragmentation issues can always be solved with pool allocation. Is the complexity only due to value-holders, or just different kind of holders? Seems to me (without having looked at instance_new/instance_dealloc yet..) like you would need the same allocation routines for pointer-holders as well.
The to-python converter that gets registered for auto_ptr<T> by using it in a class<T, std::auto_ptr<T>, ... > or by using register_pointer_to_python<std::auto_ptr<T> > knows what to do.
Ah, right. It's pretty nice to be able to hold the instances in different kind of holders.
Yeah.
Note also that shared_ptr is "magic", in that any wrapped T can be converted to shared_ptr<T> regardless of holder, and the resulting shared_ptr<T> can be converted back to the original Python object (not just a new one sharing the same C++ object).
Ok. I noticed that while browsing the code. The custom deleter is a powerful tool. :)
and even the ones that doesn't can still be used in different contexts. ('result' when doing C++ -> lua, and '_N' when doing lua -> C++).
How is that *not* a case of bidirectionality?
:) It is, my fault. I meant it could be used in different contexts with the same direction, it should read something like: 'result' when calling a C++ function, '_N' when calling a lua function.
That rule makes me nervous, because the terms are backwards when calling lua/python from C++. Do people get confused?
I don't think they do, I don't think anyone has reported any problems with it yet. It's backwards for a reason though, and it's pretty clear when to use which placeholder. (except in some special cases, where documentation helps).
OK. Maybe we could allow a default argument which would "just work" for these cases. Another option is "_", which is used in MPL for something similar.
Sure, that would be nice. You can also introduce additional placeholder aliases for the cases where '_N' and 'result' doesn't fit very well. -- Daniel Wallin
"Daniel Wallin" <dalwan01@student.umu.se> writes:
Need to think about this some more. It's no special case in BPL though, it's just another type of instance_holder, correct?
Not only that. It's an issue of where the instance holder gets constructed. In this case it is constructed directly in the storage for the Python object.
Right, that's pretty cool.
Yeah, but I doubt it's saving much, and it leads to much complication (c.f. instance_new and instance_dealloc in libs/python/src/object/class.cpp). If objects are getting created and destroyed a *lot* it could reduce fragmentation and increase locality... but as I said I have big doubts.
Yeah, fragmentation issues can always be solved with pool allocation.
But locality can't, for what that's worth. Frankly I think it's not worth much.
Is the complexity only due to value-holders, or just different kind of holders? Seems to me (without having looked at instance_new/instance_dealloc yet..) like you would need the same allocation routines for pointer-holders as well.
I'm trying to tell you it has nothing to do with the how the holders contain their data [though see below]; it's about how/where the holders themselves are constructed. The object model is something like this: every wrapped class instance contains an endogenous linked list of holders (to handle multiple inheritance from wrapped classes) and some raw storage to use for holder allocation. A class wrapper knows the size and alignment of its default holder, so usually the holder will be allocated right in the raw storage. If the holder turns out to be too big for that storage, e.g. the default holder contains an auto_ptr<T> but for some reason a value_holder<T> is used, or a value_holder<U> is used where U is derived from T, then the holder will be dynamically allocated instead. Additional holders in MI situations can also end up being dynamically allocated. Arranging for the extra storage in the Python object means we have to fool Python into thinking the objects are variable-length (like a tuple), and incurs a few other complications. Well, OK, actually I suppose the argument forwarding problem (http://tinyurl.com/fist) causes a lot of additional complexity because references need to be passed through reference_wrapper<T> arguments, and that would go away if there were no value_holders. I barely even notice that anymore, since it was part of BPLv1... but now that you mention it, value_holder is probably causing more complication in the code than in-place holder allocation. Eliminating both might be a huge simplification. Additionally, it might become possible to convert nearly any object to nearly any kind of smart pointer. value_holders impose some real limitations on usability.
The to-python converter that gets registered for auto_ptr<T> by using it in a class<T, std::auto_ptr<T>, ... > or by using register_pointer_to_python<std::auto_ptr<T> > knows what to do.
Ah, right. It's pretty nice to be able to hold the instances in different kind of holders.
Yeah.
Note also that shared_ptr is "magic", in that any wrapped T can be converted to shared_ptr<T> regardless of holder, and the resulting shared_ptr<T> can be converted back to the original Python object (not just a new one sharing the same C++ object).
Ok. I noticed that while browsing the code. The custom deleter is a powerful tool. :)
Yeah, Peter's design really is beautiful.
and even the ones that doesn't can still be used in different contexts. ('result' when doing C++ -> lua, and '_N' when doing lua -> C++).
How is that *not* a case of bidirectionality?
:) It is, my fault. I meant it could be used in different contexts with the same direction, it should read something like: 'result' when calling a C++ function, '_N' when calling a lua function.
That rule makes me nervous, because the terms are backwards when calling lua/python from C++. Do people get confused?
I don't think they do, I don't think anyone has reported any problems with it yet. It's backwards for a reason though, and it's pretty clear when to use which placeholder. (except in some special cases, where documentation helps).
OK. Maybe we could allow a default argument which would "just work" for these cases. Another option is "_", which is used in MPL for something similar.
Sure, that would be nice. You can also introduce additional placeholder aliases for the cases where '_N' and 'result' doesn't fit very well.
My point is that I'm trying to get away from a scenario where users have to think about which choice is right, when the context dictates that there can only be one right choice. Adding different names for the choices doesn't help with that problem. This is a minor nit. It sounds like we're converging quite rapidly. What other issues do we need to deal with? -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 00:34 2003-06-29, you wrote:
"Daniel Wallin" <dalwan01@student.umu.se> writes:
Yeah, but I doubt it's saving much, and it leads to much complication (c.f. instance_new and instance_dealloc in libs/python/src/object/class.cpp). If objects are getting created and destroyed a *lot* it could reduce fragmentation and increase locality... but as I said I have big doubts.
Yeah, fragmentation issues can always be solved with pool allocation.
But locality can't, for what that's worth. Frankly I think it's not worth much.
Me neither.
Is the complexity only due to value-holders, or just different kind of holders? Seems to me (without having looked at instance_new/instance_dealloc yet..) like you would need the same allocation routines for pointer-holders as well.
I'm trying to tell you it has nothing to do with the how the holders contain their data [though see below]; it's about how/where the holders themselves are constructed.
The object model is something like this: every wrapped class instance contains an endogenous linked list of holders (to handle multiple inheritance from wrapped classes) and some raw storage to use for holder allocation. A class wrapper knows the size and alignment of its default holder, so usually the holder will be allocated right in the raw storage. If the holder turns out to be too big for that storage, e.g. the default holder contains an auto_ptr<T> but for some reason a value_holder<T> is used, or a value_holder<U> is used where U is derived from T, then the holder will be dynamically allocated instead. Additional holders in MI situations can also end up being dynamically allocated. Arranging for the extra storage in the Python object means we have to fool Python into thinking the objects are variable-length (like a tuple), and incurs a few other complications.
Ok, I have very little knowledge in how Python memory management works. In luabind we always allocate dynamically. We also don't support multiple inheritance from wrapped classes.
Well, OK, actually I suppose the argument forwarding problem (http://tinyurl.com/fist) causes a lot of additional complexity because references need to be passed through reference_wrapper<T> arguments, and that would go away if there were no value_holders. I barely even notice that anymore, since it was part of BPLv1... but now that you mention it, value_holder is probably causing more complication in the code than in-place holder allocation. Eliminating both might be a huge simplification. Additionally, it might become possible to convert nearly any object to nearly any kind of smart pointer. value_holders impose some real limitations on usability.
The actual allocation of the holders could be in a language dependent layer though, in which case it would be an implementation detail if it's in-place or heap allocated. We don't have any issues with allocating the holder memory together with the instance object in lua.
That rule makes me nervous, because the terms are backwards when calling lua/python from C++. Do people get confused?
I don't think they do, I don't think anyone has reported any problems with it yet. It's backwards for a reason though, and it's pretty clear when to use which placeholder. (except in some special cases, where documentation helps).
OK. Maybe we could allow a default argument which would "just work" for these cases. Another option is "_", which is used in MPL for something similar.
Sure, that would be nice. You can also introduce additional placeholder aliases for the cases where '_N' and 'result' doesn't fit very well.
My point is that I'm trying to get away from a scenario where users have to think about which choice is right, when the context dictates that there can only be one right choice. Adding different names for the choices doesn't help with that problem. This is a minor nit.
Yeah, for those cases (object_cast, object::assign for instance) we could use default argument or a 'magic' placeholder.
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here? Daniel Wallin, dalwan01@student.umu.se
[2003-07-01] Daniel Wallin wrote:
At 00:34 2003-06-29, you wrote:
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here?
Even though I followed most of this conversation... I'd personally like to see a summary of decisions. After that finding out what I and others can help with; deciding where to put the work; what to name / where to put the common code; do we want to move the dev discussion to a dedicated list; etc. Some possible answers to those: I imagine doing some of this in the boost-sandbox project is best. Question is do we do all the dev work there or do we keep the LuaBind part where it is? I can contact Jeremy about adding Daniel and Arvid to it, so that Dave can continue enjoying his vacation ;-) As for the name of the common code, I think there was one previous suggestion which I can't remember. But my suggestion is Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms used for binding at runtime/dynamically. I would assume Boost.Lua would be the conterpart to Boost.Python. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq
Rene Rivera <grafik666@redshift-software.com> writes:
[2003-07-01] Daniel Wallin wrote:
At 00:34 2003-06-29, you wrote:
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here?
Even though I followed most of this conversation... I'd personally like to see a summary of decisions.
I think that would be great. Volunteers?
After that finding out what I and others can help with; deciding where to put the work; what to name / where to put the common code; do we want to move the dev discussion to a dedicated list; etc.
Some possible answers to those:
I imagine doing some of this in the boost-sandbox project is best.
I'm not sure; I want to refactor parts of Boost.Python anyway. Given that we have a pile of tests, etc., I think it would be better to do this evolution in the main CVS. On a branch, if nothing else.
Question is do we do all the dev work there or do we keep the LuaBind part where it is? I can contact Jeremy about adding Daniel and Arvid to it, so that Dave can continue enjoying his vacation ;-)
I think it's best to have everything in one repository so we can be aggressive about sharing architecture and technology.
As for the name of the common code, I think there was one previous suggestion which I can't remember. But my suggestion is Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms used for binding at runtime/dynamically. I would assume Boost.Lua would be the conterpart to Boost.Python.
Tie already has a meaning in the tuples library. I think we ought to consider something that has more connotations of _dynamic_ _language_ binding. It's a bit unfortunate because we probably don't like some of the connotations, but "Boost.Script" might be the most apporpriate name. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 19:33 2003-07-03, you wrote:
Rene Rivera <grafik666@redshift-software.com> writes:
[2003-07-01] Daniel Wallin wrote:
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here?
After that finding out what I and others can help with; deciding where to put the work; what to name / where to put the common code; do we want to move the dev discussion to a dedicated list; etc.
Some possible answers to those:
Question is do we do all the dev work there or do we keep the LuaBind part where it is? I can contact Jeremy about adding Daniel and Arvid to it, so that Dave can continue enjoying his vacation ;-)
I think it's best to have everything in one repository so we can be aggressive about sharing architecture and technology.
I agree.
As for the name of the common code, I think there was one previous suggestion which I can't remember. But my suggestion is Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms used for binding at runtime/dynamically. I would assume Boost.Lua would be the conterpart to Boost.Python.
Tie already has a meaning in the tuples library. I think we ought to consider something that has more connotations of _dynamic_ _language_ binding. It's a bit unfortunate because we probably don't like some of the connotations, but "Boost.Script" might be the most apporpriate name.
Script it better.. It doesn't feel good though, but it might just take some time to get used to. :) Daniel Wallin, dalwan01@student.umu.se
I think it's best to have everything in one repository so we can be aggressive about sharing architecture and technology.
I agree.
OK :-)
As for the name of the common code, I think there was one previous suggestion which I can't remember. But my suggestion is Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms used for binding at runtime/dynamically. I would assume Boost.Lua would be the conterpart to Boost.Python.
Tie already has a meaning in the tuples library. I think we ought to consider something that has more connotations of _dynamic_ _language_ binding. It's a bit unfortunate because we probably don't like some of the connotations, but "Boost.Script" might be the most apporpriate name.
Script it better.. It doesn't feel good though, but it might just take some time to get used to. :)
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc. Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-) Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind? -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq
Rene Rivera wrote:
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc.
Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-) Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?
Perhaps Boost.Export? After all, it is all about exporting C++ code to other languages... just a thought. 8)
Nicodemus <nicodemus@globalite.com.br> wrote:
Rene Rivera wrote:
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc.
Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-) Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?
Perhaps Boost.Export? After all, it is all about exporting C++ code to other languages... just a thought. 8)
Boost.Export is a good name. -- Joel de Guzman joel at boost-consulting.com http://www.boost-consulting.com http://spirit.sf.net
[2003-07-04] Joel de Guzman wrote:
Nicodemus <nicodemus@globalite.com.br> wrote:
Rene Rivera wrote:
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc.
Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-) Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?
Perhaps Boost.Export? After all, it is all about exporting C++ code to other languages... just a thought. 8)
Boost.Export is a good name.
Yes, good suggestion indeed :-) -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq
Rene Rivera <grafik666@redshift-software.com> writes:
[2003-07-04] Joel de Guzman wrote:
Nicodemus <nicodemus@globalite.com.br> wrote:
Rene Rivera wrote:
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc.
Boost.Language is a thought, but too broad. Boost.Bind is taken. ;-) Boost.Interface might work. Boost.Objects perhaps? Or Boost.ObjectBind?
Perhaps Boost.Export? After all, it is all about exporting C++ code to other languages... just a thought. 8)
Boost.Export is a good name.
Yes, good suggestion indeed :-)
Too general, IMO, as are Boost.Interface, Boost.Objects, and Boost.ObjectBind. Also almost all of the code will be specific to dynamic languages, so I don't see how Haskell can figure into this. Your other points are well taken. Another too-general name which I like better than others so far: Boost.Binding. OTOH, I think this is a bicycle shed question. Notice how many responses we got all of a sudden in this thread? <wink>. Anyway, this is just a library for library writers and I'm content to call it "the common core" until we really need a name. -- Dave Abrahams Boost Consulting www.boost-consulting.com
--- Rene Rivera <grafik666@redshift-software.com> wrote:
[2003-07-04] Joel de Guzman wrote:
Nicodemus <nicodemus@globalite.com.br> wrote:
Rene Rivera wrote:
Script has "limiting" connotations in my mind. After all what happens when we add bindings for other non-scripting languages like: Lisp/CLOS, Smalltalk, Haskell, etc. And for non-language related bindings like CORBA, COM, SOAP, XMLRPC, etc.
Hm, so many guests... it must be a Boost.Party! Ralf __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com
[2003-07-03] David Abrahams wrote:
Rene Rivera <grafik666@redshift-software.com> writes:
[2003-07-01] Daniel Wallin wrote:
At 00:34 2003-06-29, you wrote:
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here?
Even though I followed most of this conversation... I'd personally like to see a summary of decisions.
I think that would be great. Volunteers?
I can try and go through the thread, reading more carefully than the first time around, and collect some of the info. (will take a few days) And post the results :-)
After that finding out what I and others can help with; deciding where to put the work; what to name / where to put the common code; do we want to move the dev discussion to a dedicated list; etc.
Some possible answers to those:
I imagine doing some of this in the boost-sandbox project is best.
I'm not sure; I want to refactor parts of Boost.Python anyway. Given that we have a pile of tests, etc., I think it would be better to do this evolution in the main CVS. On a branch, if nothing else.
I thought that for such a restructuring you would not want to mess with the current BP, even if on a branch? But I can see that it would be easier than copying over a bunch of BP code. Any ideas/preferences on: Where do we discuss the refactoring of the common code and the laubind dev? It seems like noise polution to keep it on this list. Daniel do you have a non-user list set up for LuaBind? Or we can add a list to the SF boost project. -- grafik - Don't Assume Anything -- rrivera (at) acm.org - grafik (at) redshift-software.com -- 102708583 (at) icq
Rene Rivera <grafik666@redshift-software.com> writes:
I thought that for such a restructuring you would not want to mess with the current BP, even if on a branch?
That's what branches are for!
But I can see that it would be easier than copying over a bunch of BP code.
Yep.
Any ideas/preferences on: Where do we discuss the refactoring of the common code and the laubind dev? It seems like noise polution to keep it on this list. Daniel do you have a non-user list set up for LuaBind? Or we can add a list to the SF boost project.
I prefer here, but only a little. Those interested in Boost.Python internals (I'm thinking of people like Brett Calcott and Dirk Gerrits here) would have to subscribe to whatever other forum we pick. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 01:59 2003-07-04, you wrote:
[2003-07-03] David Abrahams wrote:
After that finding out what I and others can help with; deciding where to put the work; what to name / where to put the common code; do we want to move the dev discussion to a dedicated list; etc.
Some possible answers to those:
I imagine doing some of this in the boost-sandbox project is best.
I'm not sure; I want to refactor parts of Boost.Python anyway. Given that we have a pile of tests, etc., I think it would be better to do this evolution in the main CVS. On a branch, if nothing else.
<snip>
Any ideas/preferences on: Where do we discuss the refactoring of the common code and the laubind dev? It seems like noise polution to keep it on this list. Daniel do you have a non-user list set up for LuaBind? Or we can add a list to the SF boost project.
We don't have any non-user list, but I could add one if needed. I think I would prefer a separate list, for easy archiving purposes. :) Daniel Wallin, dalwan01@student.umu.se
Daniel Wallin <dalwan01@student.umu.se> writes:
Any ideas/preferences on: Where do we discuss the refactoring of the common code and the laubind dev? It seems like noise polution to keep it on this list. Daniel do you have a non-user list set up for LuaBind? Or we can add a list to the SF boost project.
We don't have any non-user list, but I could add one if needed. I think I would prefer a separate list, for easy archiving purposes. :)
OK, I just requested boost-langbinding@lists.sf.net. When it is activeated sometime in the next 24 hours you can subscribe at http://lists.sourceforge.net/mailman/listinfo/boost-langbinding -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams <dave@boost-consulting.com> writes:
Daniel Wallin <dalwan01@student.umu.se> writes:
Any ideas/preferences on: Where do we discuss the refactoring of the common code and the laubind dev? It seems like noise polution to keep it on this list. Daniel do you have a non-user list set up for LuaBind? Or we can add a list to the SF boost project.
We don't have any non-user list, but I could add one if needed. I think I would prefer a separate list, for easy archiving purposes. :)
OK, I just requested boost-langbinding@lists.sf.net. When it is activeated sometime in the next 24 hours you can subscribe at http://lists.sourceforge.net/mailman/listinfo/boost-langbinding
It's up now. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 02:46 2003-07-05, you wrote:
David Abrahams <dave@boost-consulting.com> writes:
Daniel Wallin <dalwan01@student.umu.se> writes:
We don't have any non-user list, but I could add one if needed. I think I would prefer a separate list, for easy archiving purposes. :)
OK, I just requested boost-langbinding@lists.sf.net. When it is activeated sometime in the next 24 hours you can subscribe at http://lists.sourceforge.net/mailman/listinfo/boost-langbinding
It's up now.
Ok great. --- Daniel Wallin
At 22:04 2003-07-01, you wrote:
[2003-07-01] Daniel Wallin wrote:
At 00:34 2003-06-29, you wrote:
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here? <snip>
As for the name of the common code, I think there was one previous suggestion which I can't remember. But my suggestion is Boost.Tie. It's on par with Boost.Bind, but tie is one of the terms used for binding at runtime/dynamically. I would assume Boost.Lua would be the conterpart to Boost.Python.
I think 'tie' is a bit vague. I don't have any suggestions at the moment though. Also, we would very much like to keep the name 'luabind'. Daniel Wallin, dalwan01@student.umu.se
Daniel Wallin <dalwan01@student.umu.se> writes:
At 00:34 2003-06-29, you wrote:
"Daniel Wallin" <dalwan01@student.umu.se> writes:
Ok, I have very little knowledge in how Python memory management works. In luabind we always allocate dynamically. We also don't support multiple inheritance from wrapped classes.
Oh, but that's cheap. At least in Boost.Python it is. I assume it would be the same in luabind if you were using holders.
Well, OK, actually I suppose the argument forwarding problem (http://tinyurl.com/fist) causes a lot of additional complexity because references need to be passed through reference_wrapper<T> arguments, and that would go away if there were no value_holders. I barely even notice that anymore, since it was part of BPLv1... but now that you mention it, value_holder is probably causing more complication in the code than in-place holder allocation. Eliminating both might be a huge simplification. Additionally, it might become possible to convert nearly any object to nearly any kind of smart pointer. value_holders impose some real limitations on usability.
The actual allocation of the holders could be in a language dependent layer though, in which case it would be an implementation detail if it's in-place or heap allocated. We don't have any issues with allocating the holder memory together with the instance object in lua.
But without value_holders it seems silly, and value_holders themselves seem to lead to a great deal of complication, soo... Looking at the big picture I'm rather inclined to go with something much simpler. I guess that using placement new in value holders might be a way to gain a whole lot of simplicity, though. OK, here's my conclusion (hope you agree): there's no need for value_holders or in-dynamic-object allocation of C++ data in any initial merged version of the library. We can always optimize later if it doesn't incur too much code complexity.
It sounds like we're converging quite rapidly. What other issues do we need to deal with?
I don't know. I'm sure more issues will pop up later on though. :) How do we proceed from here?
I think Rene raised that already; let's continue in that branch of the thread. -- Dave Abrahams Boost Consulting www.boost-consulting.com
At 01:39 2003-07-04, you wrote:
Daniel Wallin <dalwan01@student.umu.se> writes:
At 00:34 2003-06-29, you wrote:
"Daniel Wallin" <dalwan01@student.umu.se> writes:
Ok, I have very little knowledge in how Python memory management works. In luabind we always allocate dynamically. We also don't support multiple inheritance from wrapped classes.
Oh, but that's cheap. At least in Boost.Python it is. I assume it would be the same in luabind if you were using holders.
Yeah it would. The thing is that lua doesn't have classes, all it has is the ability to 'hook' on certain events on objects, so the class system is something luabind introduces. Multiple inheritance would mean we would need to make some decisions on how to handle method-dispatching, and how to handle diamond shapes. This is isolated behavior of the luabind class-system though, so it has nothing to do with the shared code. Although, we might introduce MI if there is sufficient need for it.
Well, OK, actually I suppose the argument forwarding problem (http://tinyurl.com/fist) causes a lot of additional complexity because references need to be passed through reference_wrapper<T> arguments, and that would go away if there were no value_holders. I barely even notice that anymore, since it was part of BPLv1... but now that you mention it, value_holder is probably causing more complication in the code than in-place holder allocation. Eliminating both might be a huge simplification. Additionally, it might become possible to convert nearly any object to nearly any kind of smart pointer. value_holders impose some real limitations on usability.
The actual allocation of the holders could be in a language dependent layer though, in which case it would be an implementation detail if it's in-place or heap allocated. We don't have any issues with allocating the holder memory together with the instance object in lua.
But without value_holders it seems silly, and value_holders themselves seem to lead to a great deal of complication, soo...
Looking at the big picture I'm rather inclined to go with something much simpler. I guess that using placement new in value holders might be a way to gain a whole lot of simplicity, though.
OK, here's my conclusion (hope you agree): there's no need for value_holders or in-dynamic-object allocation of C++ data in any initial merged version of the library. We can always optimize later if it doesn't incur too much code complexity.
I agree that value_holders isn't needed in the initial version, but having functions that allocate the storage for holders in language dependent code doesn't really add any complexity. Daniel Wallin, dalwan01@student.umu.se
Daniel Wallin <dalwan01@student.umu.se> writes:
At 01:39 2003-07-04, you wrote:
Daniel Wallin <dalwan01@student.umu.se> writes:
At 00:34 2003-06-29, you wrote:
"Daniel Wallin" <dalwan01@student.umu.se> writes:
Ok, I have very little knowledge in how Python memory management works. In luabind we always allocate dynamically. We also don't support multiple inheritance from wrapped classes.
Oh, but that's cheap. At least in Boost.Python it is. I assume it would be the same in luabind if you were using holders.
Yeah it would. The thing is that lua doesn't have classes, all it has is the ability to 'hook' on certain events on objects, so the class system is something luabind introduces. Multiple inheritance would mean we would need to make some decisions on how to handle method-dispatching, and how to handle diamond shapes.
I understand. Sounds like you made a good trade-off.
This is isolated behavior of the luabind class-system though, so it has nothing to do with the shared code. Although, we might introduce MI if there is sufficient need for it.
Doesn't sound like it would be worthwhile.
The actual allocation of the holders could be in a language dependent layer though, in which case it would be an implementation detail if it's in-place or heap allocated. We don't have any issues with allocating the holder memory together with the instance object in lua.
But without value_holders it seems silly, and value_holders themselves seem to lead to a great deal of complication, soo...
Looking at the big picture I'm rather inclined to go with something much simpler. I guess that using placement new in value holders might be a way to gain a whole lot of simplicity, though.
OK, here's my conclusion (hope you agree): there's no need for value_holders or in-dynamic-object allocation of C++ data in any initial merged version of the library. We can always optimize later if it doesn't incur too much code complexity.
I agree that value_holders isn't needed in the initial version, but having functions that allocate the storage for holders in language dependent code doesn't really add any complexity.
Agreed. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (6)
-
Daniel Wallin -
David Abrahams -
Joel de Guzman -
Nicodemus -
Ralf W. Grosse-Kunstleve -
Rene Rivera