On Monday, June 12, 2017 at 7:03:13 PM UTC-5, Mark wrote:
>
> Yes, I think most of the problems can be solved through prefixing
> (although the solution is a bit hacky, IMO) but the real problem with the
> global registry is that its not based on an abstraction but a concrete
> implementation.
On Monday, June 12, 2017 at 7:42:53 PM UTC-5, Sean Corfield wrote:
>
> If you’re building a multi-tenant system, then this is not how you do it:
>
I think Sean covered it - this seems like a problem with the design of this
service.
--
You received this message because you are subscribed to t
On Monday, June 12, 2017 at 5:24:23 PM UTC-5, Gregg Reynolds wrote:
>
>
>
> On Jun 12, 2017 4:55 PM, "Alex Miller" wrote:
>
> I think it's your responsibility to make specs "sufficiently unique".
> Prefixing with a standard namespace you control seems like it would work.
>
>
> pls excuse me for
If you’re building a multi-tenant system, then this is not how you do it:
> One customer wants :org/postcode to be integer (i.e. US) and another wants it
> to be string (i.e. UK)
In a multi-tenant system, you have very few “global truths” and for _anything_
that an end-user may touch, it
Yes, I think most of the problems can be solved through prefixing (although
the solution is a bit hacky, IMO) but the real problem with the global
registry is that its not based on an abstraction but a concrete
implementation. The only specific problem I can think of right now is the
incidental co
I can think of a use-case in support of Mark's position.
If you are building a hosted ETL web service (like Mulesoft) and you want
users to be able to use spec to validate records flowing through it.
One customer wants :org/postcode to be integer (i.e. US) and another wants
it to be string (i.
On Jun 12, 2017 4:55 PM, "Alex Miller" wrote:
I think it's your responsibility to make specs "sufficiently unique".
Prefixing with a standard namespace you control seems like it would work.
pls excuse me for butting in, but i wonder what happens when i require 14
namespaces and 7 of them regist
I think it's your responsibility to make specs "sufficiently unique".
Prefixing with a standard namespace you control seems like it would work.
There is an enhancement winding through jira to support the ability to
remove a spec from the registry by doing (s/def ::foo nil) and I expect
that to
> What problem would be solved by each customer having his own registry?
Name clashes (to be fair, elsewhere on this thread, Sean Corfield suggested
prefixing and this would certainly work).
> What do you mean by retracting specs? And what problem would this solve?
Retracting a spec means t
On 12 Jun 2017, at 20:41, Mark wrote:
> > I don't see how that limits it to dev use cases. Can you explain more why
> > you say that?
>
> I understand (and completely agree with) the assumption of a global namespace
> for spec names. The scope of that namespace is all Clojure developers. I
Yeah, I can see how to make it work but I'm worried about lifecycle issues.
What if my customers insist on the ability to retract a spec? Showing
them a Rich Hickey video is not a particularly good response :) Leaving
that aside, users who just play around risk polluting the global registry
> I don't see how that limits it to dev use cases. Can you explain more why
you say that?
I understand (and completely agree with) the assumption of a global
namespace for spec names. The scope of that namespace is all Clojure
developers. I want a different scope: the users of my app. To c
So, you would give all those end-user-created specs a unique namespace prefix
which identified them as part of your application. As Alex indicated, spec is
predicated on the use of appropriately qualified names, so that they have
global meaning.
Sean Corfield -- (970) FOR-SEAN -- (904) 302-S
'm thinking of exposing the spec machinery to my app's end users who would
build specs (probably using a graphical tool) to facilitate building data
pipelines. It seems that the global registry assumes a particular
lifecycle for specs which is probably perfect for developer-centric use
cases.
On Monday, June 12, 2017 at 1:36:53 PM UTC-5, Kevin Baldor wrote:
>
> I'm interested in the answer to whether it is just an accident of
> implementation or if there is some compelling reason for the global
> registry.
>
With spec we wish to encourage the use of attributes with good (qualified)
Can you explain why you think this is the case Mark?
We use spec heavily in production (and have been doing so for months) so I’m
not following your logic here I’m afraid…
Sean Corfield -- (970) FOR-SEAN -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
"If you're not annoying
On Jun 10, 2017 11:57 AM, "Mark" wrote:
I'm embarking on a new project and I think spec can be a central component
not just to the developer-users of the system but to my end-users as well.
I'm thinking of providing something like a graphical mechanism to describe
specs in EDN to bring spec goodn
I'm interested in the answer to whether it is just an accident of
implementation or if there is some compelling reason for the global
registry.
I'm still new to Clojure and it would be good to hear the tradeoffs and
design process that led to the current implementation.
On Mon, Jun 12, 2017 at 1
I'm a bit surprised by this. It seems that the use of the global registry
limits spec to development use cases. Is that intentional? Maybe I'm
worried over nothing
On Saturday, June 10, 2017 at 11:04:17 AM UTC-7, Alex Miller wrote:
>
> We don't have any plans at the moment to support anything
Specter supercharges your ability to use and manipulate data structures in
Clojure and ClojureScript. 1.0.2 contains minor
improvements. https://github.com/nathanmarz/specter
Full changelog:
* Added `pred=`, `pred<`, `pred>`, `pred<=`, `pred>=` for filtering using
common comparisons
* Add `ma
Hey, cool that you are doing this and continuing to maintain the Clojure
variant.
--
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
21 matches
Mail list logo
