Hi,<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div><div class="Wj3C7c">On Wed, Jun 11, 2008 at 10:23 AM, Alexander Lamb<br>

<alexander.lamb@rodanotech.ch> wrote:<br>> My Erlang modules are mainly a server to Java Web applications (for<br>
> the time being).<br>> This means that I am making a big use of the Erlang Java API which<br>
> works fine.<br>
> Since my Erlang modules use Mnesia to store data coming from the Java<br>
> side (and vice versa), I need to implement functions with many<br>
> parameters for example to insert new data in a Mnesia table.<br>
> I also need to convert tuples into actual Java objects when reading<br>
> data.<br>> This would be simpler if the Java API had an OtpErlangRecord. It would<br>
> make it possible to subclass it and could even be the prefered way of<br>
> bridging the Erlang world with the Java world. </div></div></blockquote><div><br>As Gleb pointed out, records are module local, and their name alone isn't enough to tell them apart. <br><br>There is nothing that stops you to create your Java objects with a constructor (or factory method) that takes an OtpErlangTuple as a parameter and converts it to its Java counterpart. Conversely, a method similar to toString, named for example toErlang, would make the opposite conversion. Compared to an automatic conversion, this allows mappings that are more complex that one-field-to-one-field.<br>
<br>The downside is that in most cases, this is boilerplate code. <br><br>best regards,<br>Vlad<br><br><br><br></div></div><br><br>