>
> I disagree with this - you can define specs in a way that is very granular
> and gives fine-grained errors.
I'm not arguing that at any point. However, once you use a predicate to
check a tree you'll only ever be reported the root of the tree as problem
location.
The problem where it is falling down for you is the notion of some generic
> spec + later (dynamic) refinement. We have no intention of adding anything
> like that beyond what is already provided (things like s/and).
Is there a reasoning behind this? Does it clash with the ideas of spec?
Note that I'm not altering any existing, globally registered spec but
creating a new one that will only validate a subset of whatever base spec
was given.
You are seeking to refine specs dynamically based on runtime state, then
> validate additional data in terms of those (stateful) specs.
Not necessarily – it's all about separating the output of one component
(like a parser) from the constraints imposed by another. For example, I
might have a reader that produces a seq like the following:
[{:config/key "host", :config/value "myhost"}
{:config/key "port", :config/value "8080"}]
There might be multiple applications using this reader and they might have
different expectations regarding allowed values for ":config/key" (which
the reader just specs as being a string). Those values would be statically
declared within the application, no runtime state whatsoever.
Again, I _can_ do this with a predicate and "s/and" but errors produced by
spec won't help me find the problem location.
[...] then validate additional data in terms of those (stateful) specs.
They are not stateful in my proposal. The spec used is a completely new one
(based on some existing one) that will always behave the same – unless the
original spec, or part of it, is changed in the registry.
But the use of specs with dynamic variables in particular seems
> questionable - you've created a stateful spec whose meaning changes over
> time. To me, this seems like a bad idea (for all the same reasons stateful
> mutable objects introduce problems).
I'm glad we're on the same side here, seeing as I summarised the example
you're referring to with "[...] not a very clean solution, in my opinion.".
(I didn't choose the word "bad" here because it implies that there is a
better one.)
Also, "changes over time" is a questionable description of that I wrote
since rebinding a dynamic variable only affects a very localised context,
not the global state.
Instead, I think it is far preferable to dynamically generate static specs
> (which might incorporate parts of existing static specs for the purposes of
> refinement), than to statically define dynamic specs.
And what you described in the first part of that sentence is what I'm
looking for: A way to take an existing spec and wrap it to be more
restrictive than before – all the guarantees of the original spec still
hold, the registry is not touched.
I think the distinction of structural vs semantic is hazy at best (and more
> likely not even meaningful) in a predicative dynamic system.
See my above example with the configuration tuples – it demonstrates that
structure can indeed be independent from its domain specific interpretation
(even if no dynamic data is involved). It's not hazy – but very meaningful.
Getting a bit more concrete, I think this would be a better approach to the
> variable name spec:
> (defmacro make-name-spec
> [var-names]
> `(s/and :lang-name ~var-names))
> which can be called in the process of verifying the ast to dynamically
> create a static spec, which can then be used for validation. OR have
> make-name-spec use s/def to register the spec (but then you need to be
> aware that it's in the registry and has affected runtime state - that's
> where tracking the lifecycle becomes important).
I mentioned in my original message that registering a spec dynamically
generated from runtime data will lead to many problems and increased
complexity. And without that, I fail to see how this examples addresses any
of the concerns I'm voicing.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
