[erlang-questions] R14B gen_tcp:recv/2,3

[Bengt Kleberg]

I like that Erlang/OTP is working towards consistency.


bengt

On Fri, 2010-09-17 at 11:54 +0200, Ingela Andin wrote:
> Hi!
> 
> This change does break backwards compatibility.  The reason we changed
> it was that we want  gen_tcp and ssl to behave the same, if possible.
> Ssl did behave according to the documentation and in the intended way,
> so the gen_tcp behavior is considered a bug.
> Either way to make them behave the same we had to break backwards compatibility
> for either gen_tcp or ssl. Also http-packet mode has not been
> supported very long,
> actually we made it supported for the sake of ssl so that new ssl could
> support http-packet mode and not break applications using it.
> As for supporting more than one OTP-version, it should be no problem having a
> error clause that will be dead code in R14 and do something in
> previous versions.
> The content of the http_error tuple should not be any different from before.
> 
> Regards Ingela Erlang/OTP team - Ericsson AB
> 
> 
> 2010/9/17 Bengt Kleberg <bengt.kleberg@REDACTED>:
> > One more thing. I hope you are not contemplating having different
> > versions of your code for different versions of the erlang VM.
> >
> > If you code like this:
> >
> > case gen_tcp:recv(Sock, Len, RecvTimeout)
> > of {ok, {http_error,String}} -> {error, Reason}
> > ; {ok, Bin} -> {ok, Bin}
> > ; {error, Reason} -> {error, Reason}
> > end.
> >
> > it will work on both versions of the erlang VM.
> >
> >
> > bengt
> >
> > On Fri, 2010-09-17 at 09:29 +0200, Roberto Ostinelli wrote:
> >> > Greetings,
> >> >
> >> > If (I have not read the document) gen_tcp:recv/2,3 returns {ok,
> >> > {http_error,String}} your have a matching clause. Unfortunately the
> >> > match means that Bin will be {http_error,String}, which is probably not
> >> > what you want.
> >> >
> >>
> >> hi bengt,
> >>
> >> my code was just making a statement and is indeed incorrect.
> >>
> >> i do have quite some code which relies on {packet, http} and passive
> >> mode, so i believe i might be confronted with adding code which
> >> handles running on different versions of the erlang VM. *if* i'm
> >> not misunderstanding, this does break backwards compatibility and i'm
> >> quite surprised, to the point i'm asking this list for confirmation.
> >>
> >> r.
> >
> >
> > ________________________________________________________________
> > erlang-questions (at) erlang.org mailing list.
> > See http://www.erlang.org/faq.html
> > To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
> >
> >