I would just change the name of your own function. You can of course extend the existing method, but then it has potential to cause confusion. There is no confusion if you just use a different name, only slight inconvenience.
To give a more complete answer: you can also just import the functions from Cairo that you do use, if there are only a few of them. Then Cairo.image wouldn’t be in your namespace, and you could define your own image function without issue.
No you should not have this problem. This should only happen if you have actually used image.
Since you are seeing the error, it means that you are actually using image from Cairo in which case you need to decide why you are using it and if the new function you are defining agrees with that usage. OTOH, if you only have a ::Int parameter then extending Cairo.image is definitely type piracy and you must not do that. You can either change the name of image, since you are actually using two functions, or you can define your own image that fallbacks to Cairo's with image(args...; kws...) = Cairo.image(args...; kws...).
Okay that helps. This was all happening when I was still fixing various coding errors. So at a guess my image method was called when there was an error compiling the my image() method. That pulled in Cairo’s method definition so that when I fixed my image() method, I ended up with a conflict.
Don’t do this. This kind of code is exactly how you can get into the situation like this. By using using, the user doesn’t have to know anything about any new function being imported. However, if you are importing everything implicitly, a new symbol will always cause a conflict. The symptom of the conflict will not be the same but it’s just as bad (and worse, since you may not get a very obvious error when there’s a conflict)
This is fine. IIRC OpenCL does this too.
The idea of this macro is OK, However, the implementation
is bad. Never, ever use string manipulation in a macro like this. Never. It’s not even that hard to come up with a case that completely break your code.
I believe as long as you’ve defined image before using it this would not be a problem. Even if your image is missing method or is raising an error the name resolution shouldn’t fallback to imported ones after your own is defined.
In another word, if you truely don’t need image from Cairo you might have got into this situation in current session by calling image before defining it (i.e. that error has a persistent side-effect). It wouldn’t matter in a new session as long as you defined image before using it. You can still use the image from Cairo by Cairo.image, which, IMO, is a better way to use such a generic name in any case…
I would argue instead for using the generic name but when it is actually package specific just don’t export it and document it as having to be fully qualified to use.
When it’s a simple operation, you should be allowed to use a simple name for it. All what you need is namespace and that’s exactly what modules are… No need to reinvent the wheel by encode that namespace in the name itself.
That’s why I made a syntax for it. User importMX only when he is sure that there is no conflict. Otherwise, they just should call regularly.
My code works in any-case that someone has written a valid Julia code. I don’t wanna make my code slower, make developing it hard, and deal with args when I just wanna do a find and replace. There are two solutions for the problem, but I chose the best. This stereotype that “never use string manipulation inside a macro” doesn’t mean much to me when there is no solid rationale behind it.
The point is that how can someone be sure that there is never going to be a conflict in the future? Do you have a list of names that you’ll never use or a list of names that you’ll only use?
(and FWIW, if this is only to be used when there’s no conflict then by all mean it is not a solution to the issue metioned in this thread. If you do have a strict naming rule that you follows, then yes, that’ll make this macro a valid thing to have and that rule itself is a valid, albiet unusual, solution to the issue of name conflict.)
Nope. It doesn’t work if the use have a "Attributes" in the code, or :Attributes FWIW.
It’ll by all mean make your code faster by reducing the amount of work to do since what you want to do is a syntax replacement and not a string one.
It’s not a sterotype. It might not mean much to you right now and if it works for you right now you are certainly free to use it. Just be careful when it bite you inevitably sometime later.
I have little problem when people write code like this and I’ve even done much worse when I know it’s a throw away code. However, it is definitely not some code that you can recommend to other people publically. The correct way to write a micro may not mean much to you but it certainly mean a lot for maintaining a minimum level of code quality over the whole ecosystem.
So are you saying your package will never ever have a new name added?
And just to be clear, I’m talking about compatibility when new functions are added. i.e.
Of course whatever you do, your downstream can always be fixed accordingly. That’s fine for throwaway code or small personal project. However, if you are ever a upstream with hundreds of downstream, doing so unnecessary won’t be acceptable. Having something mentioned in the document has nothing to do with this unfortunately. Currently, documenting the package has exported certain names does not mean that the package does not export more, for exactly the reason that no one I know can predict the future. However, you are making that (absense of future exported names) part of the API that the user can depend on so any addition to the document or the code is now a breaking change. (Hence why I say this is making the issue worse, and in a subtle way)
I assume you meant in front, but that’s not the point. Your code are capturing f() = g("Attribute") and f() = g(:Attribute) where it shouldn’t be