Re: Spec without global registry?

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 >

Re: Spec without global registry?

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

Re: Spec without global registry?

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. >

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

> 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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without 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

Re: Spec without global registry?

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)

Re: Spec without global registry?

'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.

Re: Spec without global registry?

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)

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

Re: Spec without global registry?

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

[ANN] Specter 1.0.2 released

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

Re: clj-duckling

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