Fields

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Fields

John Moeller
I noticed that in Boost.Python, you can define a class such as this that
lets you wire fields into a Python class (from the Exposing Classes
tutorial):

class_<Var>("Var", init<std::string>())
     .def_readonly("name", &Var::name)
     .def_readwrite("value", &Var::value);

It seems that it's possible to override field access in Python, and
possibly other languages.  Because Langbinding will possibly connect to
languages where this is not possible (such as Java) -- not without some
kind of sync routine -- is there a plan to support these constructs in a
reduced fashion, or would these constructs be removed?

I could see exposing some kind of get/setField, or some such, in lieu of
the field access override.  Something like getName, getValue, and
setValue might be made available in the above example for those
languages, and languages like Python could still use them as fields.

--

John Moeller
[hidden email]


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding
Reply | Threaded
Open this post in threaded view
|

Re: Fields

Rene Rivera-2
John Moeller wrote:

> I noticed that in Boost.Python, you can define a class such as this that
> lets you wire fields into a Python class (from the Exposing Classes
> tutorial):
>
> class_<Var>("Var", init<std::string>())
>      .def_readonly("name", &Var::name)
>      .def_readwrite("value", &Var::value);
>
> It seems that it's possible to override field access in Python, and
> possibly other languages.  Because Langbinding will possibly connect to
> languages where this is not possible (such as Java) -- not without some
> kind of sync routine -- is there a plan to support these constructs in a
> reduced fashion, or would these constructs be removed?

They would not be removed...

> I could see exposing some kind of get/setField, or some such, in lieu of
> the field access override.  Something like getName, getValue, and
> setValue might be made available in the above example for those
> languages, and languages like Python could still use them as fields.

It would be up to the specific language binding to decide how to expose
all the functionality. So, yes, adding get/set methods would make sense
for Java. Or perhaps some sort of value wrapper with set() and get().


--
-- Grafik - Don't Assume Anything
-- Redshift Software, Inc. - http://redshift-software.com
-- rrivera/acm.org - grafik/redshift-software.com
-- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Boost-langbinding mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/boost-langbinding