Comments (10)
See also similar bug on aero: juxt/aero#44
from integrant.
Thanks for pointing this out. While edn says that tags should be prefixed, I have two reservations:
#integrant/ref
is a quite a bit more to type than#ref
- We're not really using the config file to communicate with anything other than Integrant
Remember also that:
(ig/read-string "foo.edn")
Is just a shortcut for:
(edn/read-string {:readers {'ref ig/ref}} "foo.edn")
And with Aero, you could write:
(defmethod aero/reader 'integrant/ref [_ _ value]
(ig/ref value))
I think that in the rare circumstance that an un-namespaced #ref
actually matters, you could instead use the edn/read-string
function directly.
from integrant.
It's also worth pointing out that Datomic "cheats" in this fashion as well. In transactions, #db/id
is used as a tag, rather than #datomic.db/id
or #datomic/id
. The rules are bent slightly for the purposes of brevity.
from integrant.
I've not looked at the details, but will your proposal work, if you have a file containing both aero and integrant refs? You should ideally be able to use the same tags in the same file, it's the whole point of edn being extensible.
Like integrant aero also defines a #ref
, so how can you disambiguate an aero ref from an integrant one? Aero have agreed to prefix them with #aero/ref
and support a deprecated legacy function for non prefixed ones (see juxt/aero#44 ), so the problem won't happen if they do that; but I think the burden is on all projects to namespace to prevent collisions such as this.
I'm all for bending the rules for brevity, aero plan to do it, and I'd certainly vote for an #ig/ref
.
from integrant.
You can just give the integrant refs a different name. As I said in my previous comment:
(defmethod aero/reader 'integrant/ref [_ _ value]
(ig/ref value))
So if you added that, you'd have #ref
(or #aero/ref
) for Aero refs, and #integrant/ref
for Integrant refs. If you wanted brevity, you could also write:
(defmethod aero/reader 'ig/ref [_ _ value]
(ig/ref value))
You can't use ig/read-string
and aero/read-config
together anyway, so there's no chance of it clashing by default, and since the configuration is a local resource, we don't expect anyone else to read it directly, either.
from integrant.
I just watched the CodeNode video and had the same concern about the unqualified #ref. The potential for real-world conflicts is admittedly small within the scope of integrant config files, but it could be worse if integrant-style data was incorporated into some larger data format or processed by external tools. Probably at this point, you don't want to change your notation or invalidate existing config files. Perhaps, as a compromise, you could add an additional qualified tag, like #ig/ref, as a documented option doing the exact same thing. That would only take a small addition to ig/read-string. It would allow people who care to follow the Clojure rules to do so, and still be able to share config data without requiring extra user code.
from integrant.
The issue with unqualified tags is that a future version of Clojure might define a meaning for the unqualified tag.
from integrant.
I don't have any problem with breaking backward compatibility in pre-1.0 versions, as long as there's a good reason. I'll think about this a little more.
However, I don't currently see there's any problem using #ref
as the default data reader for integrant.core/ref
. And if using #ref
does become an issue, then it's trivial to switch to a different symbol for the data reader.
from integrant.
I just got around to looking at integrant and came here to file this issue. :)
In this particular case, of all the words you could pick, ref seems like it's near the top of the list as one of the most likely ones to conflict with potential core usage.
What about #ig/ref?
from integrant.
I'm leaning toward changing it to #ig/ref
, but I'd like to think about it some more. In the meanwhile, it's trivial to change the data reader symbol to whatever you want; #ref
is just the default.
from integrant.
Related Issues (20)
- Would you consider an integrant2 to support extensible build steps? HOT 10
- Why does resume halt unspecified system keys? HOT 4
- Support usage in Babashka environments HOT 20
- #{:idea} Pass the spec validations step on all defined states before calling init-key. HOT 1
- is it possible to access a component after it's init-key, but before it gets passed to the next key that depends on it? HOT 2
- Enter Integrant Video
- Add support for custom assertf definitions HOT 2
- Question: Extract "validation keys" logic from core/build implementation HOT 4
- Feature request: pre-init hook
- No method in multimethod 'init-key' for dispatch value HOT 2
- #ig/ref should allow for deep references HOT 1
- Uninitialized/literal configs HOT 1
- Tests don't run with 1.11 due to clojure.test/run-test already being defined HOT 1
- Feature proposal: expand-key HOT 2
- Any way to add constant key in `edn`? HOT 2
- Unable to access Presentations(Enter Integrant) HOT 3
- Perhaps use metadata as an alternative to resolve-key? HOT 2
- Refs/Refsets not preserved after expansion HOT 1
- Convenience tag to add methods for static keys HOT 1
- Is there a way to analyze components at the repl with their config resolved ? HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from integrant.