Skip to content

Conversation

@gar1t
Copy link

@gar1t gar1t commented Sep 30, 2014

No description provided.

@choptastic
Copy link

This will throw a fit with anything below Erlang 17 though. I imagine the safer solution, at least until 18 is out, would be to just suppress the deprecation warnings, no?

/home/travis/build/Eonblast/Emysql/src/../include/emysql.hrl:39: referring to built-in type queue as a remote type; please take out the module name

@jlouis
Copy link
Collaborator

jlouis commented Oct 1, 2014

The right solution is probably to branch off a development path and keep 'master' stable. There are so many things I want to do to emysql but the problem is I have to obey the old API. Having a branch-point with 17+ support could be a way to work around this.

@gar1t
Copy link
Author

gar1t commented Oct 1, 2014

Kinda feels like the forking problem that you worked so hard to reign in.
Though gods know this API could use a complete overhaul so I actually like
the sound of this.

A couple other thoughts here:

  • Skip the typespecs altogether and leave them for docs
  • Conditional compilation based on erlc library version (ugh)

The problem with ignoring the compilation warnings is that this problem is
exported via the hrl include, which you need to use this library. It
infects every module you use for database access. There are lots of
projects that require that warnings be treated as errors to make this an
actual problem, IMO.

On Wed, Oct 1, 2014 at 8:39 AM, Jesper Louis Andersen <
[email protected]> wrote:

The right solution is probably to branch off a development path and keep
'master' stable. There are so many things I want to do to emysql but the
problem is I have to obey the old API. Having a branch-point with 17+
support could be a way to work around this.


Reply to this email directly or view it on GitHub
#148 (comment).

@choptastic
Copy link

How about this?choptastic@a80db4c

It works like the existing crypto_compat script and creates types emysql_dict, emysql_queue (using dict() for <17 and dict:dict() for 17+) which can then safely be pulled into apps and allows us to remove the "nowarn_deprecated" flag.

I briefly tested it with 17.3 and R16B.

@jlouis
Copy link
Collaborator

jlouis commented Oct 1, 2014

Could work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants