You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This should probably be written up as a change proposal but I've opened up this issue first to get feedback.
There is a simple gotcha with pony use strings. If you're working within a file that wants to use some library, "xyz" and that file is next to a directory xyz, then it will always resolve to that location, even if there is no pony code within that directory. This might seem like an intended trade but it can make certain cases in multi-language projects a bit more difficult when directory names and layout might collide.
As I see it, there are two reasonable fixes that come to mind. We could only resolve it as a package directory if there is at least one pony file in that path or we could make local resolution relative in all cases. The latter seems to be a little clearer, like C does with #include "xyz.h" vs #include <xyz.h>.
The impact is minor but widespread since there is a lot of code which would now require a ./ prefix on the path. Pony could warn when something should be prefixed as a local path before making this kind of change.
The text was updated successfully, but these errors were encountered:
So I'd be fine writing something longer form up but the open question of how much people would be against the implicit local path vs making relative paths the default way to include local sources rather than pony-stable managed, standard library packages, and anything else that may reside on configured compilation paths. I expect a lot of friction on this kind of change so I wanted to get a feeling for what concerns people have so I can address them appropriately.
My explanation above is a bit short so perhaps it's hard to discuss but unless there's more of a summary judgement from the existing community, I'll assume the discussion of path conventions in an RFC would be useful (even if we don't change anything in the end).
This should probably be written up as a change proposal but I've opened up this issue first to get feedback.
There is a simple gotcha with pony use strings. If you're working within a file that wants to use some library, "xyz" and that file is next to a directory xyz, then it will always resolve to that location, even if there is no pony code within that directory. This might seem like an intended trade but it can make certain cases in multi-language projects a bit more difficult when directory names and layout might collide.
As I see it, there are two reasonable fixes that come to mind. We could only resolve it as a package directory if there is at least one pony file in that path or we could make local resolution relative in all cases. The latter seems to be a little clearer, like C does with
#include "xyz.h"
vs#include <xyz.h>
.The impact is minor but widespread since there is a lot of code which would now require a
./
prefix on the path. Pony could warn when something should be prefixed as a local path before making this kind of change.The text was updated successfully, but these errors were encountered: