<div dir="ltr">Hi Dmitriy,<div><br></div><div>I'm still going through your code, but I wonder if you could explain why equals should be implemented in terms of match? I think these are two different operations and can be relevant only if checking equals between a regular term and a pattern, but I can't see any reason to want to do that because these should never be equal. Or maybe I am missing a fine point?...</div><div><br></div><div>I am also wondering if OEObject itself could implement OEMatcher and just call match/bind recursively instead of checking "instanceof OEMatcher" in OEList, OEMap and OETuple. It feels easier to understand (less conditionals in the code).</div><div><br></div><div>In my implementation, I did it in a slightly different way, mostly in order to modify existing classes as little as possible, by using an utility class to traverse terms and do matching and binding. I also have more advanced conversion routines between Java and Erlang types (most useful are for Strings, List<->list and Array<->tuple/binary). Maybe you would like to check at <a href="https://github.com/vladdu/otp/compare/erlang:master...jinterface_new_api">https://github.com/vladdu/otp/compare/erlang:master...jinterface_new_api</a>?</div><div><br></div><div>Maybe we should try to unify our code first and then submit it to OTP? </div><div><br></div><div>Happy New Year and I guess that for you it's even Merry Christmas in a week, right?</div><div>Vlad</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 31, 2014 at 5:31 PM, Dmitriy Kargapolov <span dir="ltr"><<a href="mailto:dmitriy.kargapolov@gmail.com" target="_blank">dmitriy.kargapolov@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>Hi Vlad,<br>
Thank you much for your notes.<br>
<br>
I agree some names were not good enough, I changed these per your
suggestion.<br>
Old comment removed as well.<br>
<br>
As to OtpErangMap class - I was not going to re-implement it
initially. But in order to add match/bind I had to do this. I
tried to not add much new methods, keeping implementation rather
"just enough" to work with maps. You are very welcome to
add/change whatever you see reasonable in separate PR though.<br>
<br>
Best Regards and Happy New Year!<br>
- Dmitriy.<span class=""><br>
<br>
git fetch <a href="https://github.com/x0id/otp.git" target="_blank">https://github.com/x0id/otp.git</a>
jinterface_pattern_matching<br>
<br>
</span><a href="https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching" target="_blank">https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching</a><br>
<a href="https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching.patch" target="_blank">https://github.com/x0id/otp/compare/erlang:master...jinterface_pattern_matching.patch</a><div><div class="h5"><br>
<br>
On 12/31/2014 10:27 AM, Vlad Dumitrescu wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr">Hi Dmitriy,
<div><br>
</div>
<div>Nice implementation! I have something similar that I wanted
to submit, but I like some of your details better.</div>
<div><br>
</div>
<div>I have a few comments, after browsing the code just
briefly:</div>
<div><br>
</div>
<div>- I would prefer to have the OEMap changes as a separate
PR, as it's a separate issue and there are more things to
address there, like for example, OEMap could also implement
Map, like OEList implements Iterable (and might implement
List). </div>
<div>- I don't like the name OEVarrier, it doesn't mean
anything. Maybe OEMatcher would be better?</div>
<div>- OEBind might be clearer as OEBinding, as it contains a
set of bindings?</div>
<div>- I think there are still some merge issues, like for
example OEList:299 where the comment is from the old equals
method</div>
<div><br>
</div>
<div>best regards,</div>
<div>Vlad</div>
<div><br>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Tue, Dec 30, 2014 at 9:56 PM,
Dmitriy Kargapolov <span dir="ltr"><<a href="mailto:dmitriy.kargapolov@gmail.com" target="_blank">dmitriy.kargapolov@gmail.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">This
implements functionality similar to following C functions,
which are part of erl_interface application:<br>
- ETERM *erl_format(FormatStr, ...);<br>
- int erl_match(ETERM *Pattern, ETERM *Term);<br>
<br>
To acheve this new classes introduced:<br>
* OtpErlangVar - variable placeholder;<br>
* OtpErlangBind - variable values collection;<br>
* OtpErlangParser - "erl_format" parser implementation;<br>
* OtpErlangPattern - pattern abstraction with match/bind
functions;<br>
<br>
Classes representing composite objects OtpErlangList,
OtpErlangTuple, OtpErlangMap and new OtpErlangVar implement
interface OtpErlangVarrier defining match and bind functions
for these objects.<br>
<br>
Class OtpErlangMap reworked to be based on HashMap instead
of two separate lists keeping keys and values. This is close
to native semantics of maps and makes easier implementing
basic map manipulations.<br>
<br>
It addition to OtpErlangBind custom user's class may be used
as receiver of matched variables values. Java reflection is
used to prepare variable value setters during the parse
stage. Java doc has more details and examples. Test cases
implemented.<br>
<br>
git fetch <a href="https://github.com/x0id/otp.git" target="_blank">https://github.com/x0id/otp.git</a>
jinterface_pattern_matching<br>
<br>
Thanks.<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/listinfo/erlang-patches</a><br>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>