Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed deprecation warnings #148

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fixed deprecation warnings #148

wants to merge 1 commit into from

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