Clojurians Log v2

Is there a want for symbol aliases that don't require reified namespaces as well? Or just for keyword aliasing?

an excellent question we have considered. I don't have a use case for lightweight symbol aliases right now but would be curious to see one if you find one. symbols don't have auto-aliasing so that's one context that doesn't exist.

I don't have one either, was just curious.

By the way, I don't know if it helps. But where I've landed with my experimentation is something very similar to how symbols and namespaces work. I quickly details it here: https://clojureverse.org/t/spec-ing-entities-and-how-to-organize-the-specs-and-our-entity-keys-a-new-approach/6817/8?u=didibus

Bleh

Stateful non-lexical scope is gross

Is it not lexical? I think it is

If you look at just in-scope by itself what does it mean?

You have no way to know

Or I guess defalias by itself

Well, you know that every line of code after it which calls defalias will use the in-scope namespace

Same as in-ns

Bleh

Hate it :)

The only "tricky" part, similar to in-ns, is that the scope isn't put inside of a delimiter block, but is flat

Haha, well I agree with you a little. But the alternative was:

(with-scope [<http://com.app|com.app> :alias [user]]
  (defn ...)
  (defn ...)
  (s/def ...)
  (s/fdef)
  (def)
)

Which completely messed up clj-kondo. And felt less Clojury. Kind of gave me vibes of Java Classes actually (which is interesting, since its really the same problem of Entity scope that OOP has that I have here as well. I'll see how it goes in practice, but for now it works pretty much the same as symbols and namespaces, so I've found it quite intuitive. Like I'm already used to symbols having an implicit namespace that is defined by some preceding call to ns or in-ns. So this felt normal.

There's a chance I drop the in-scope as well, and just accept the fact I'm going to be using defalias like:

(defalias 'user 'com.org.app.user)
(defalias 'transact 'com.org.app.transact)
(defalias 'account 'com.org.app.account)
(defalias 'cart 'com.org.app.cart)

Well, ok, had to rethink this again 😛 If Alex Miller don't like it, something must not sit right with it lol. And I realized the only reason for my in-scope was that I was currently sprinkling the defalias call throughout my data-model namespace, above their corresponding s/keys for each. But I don't need to do that. Then I can scope all alias in a single block, put it at the top (and ideally ns could be extended to have an :alias option as well, making it even better.

(ns com.org.app.data-model ...)

(alias '[<http://com.org.app|com.org.app> :as app :refer [user account transact cart]]
       '[com.org.other-app :as other-app :refer [user] :rename {user other-user}])

::user/name
;; =&gt; :com.org.app.user/name

::app/user
;; =&gt; :<http://com.org.app/user|com.org.app/user>

::other-user/name
;; =&gt; :com.org.other-app.user/name

Not sure about the DSL here. Maybe it doesn't have to shoehorn :refer and :as and :rename, could use some other DSL. But I think with this one, I'll be able to tell clj-kondo to lint it as require and it should work which is nice.

I don't know what problem you're trying to solve at this point

why do want renaming and referring? just seems like a lot of stuff to make it as hard as possible to understand what kw you're actually using

Say I have a map which models a Person's Name:

{:name "John Doe"}

{:first-name "John"
 :last-name "Doe"}

And imagine my function that uses those is this:

(ns foo.bar
  (:require [com.org.my-app.name :as name]
            [com.org.some-dep.name :as other-name]))

(defn name->other-type-of-name
  [name]
  {::other-name/name (str (::name/first-name) "." (::name/last-name))})

(s/fdef name->other-type-of-name
  :args (s/cat :name ::name/name)
  :ret ::other-name/name)

So here I'm using the normal ::. It means that each entity must be in their own namespace so I can require each one, so imagine I also had a map called group, and account, and all that, and I didn't want their spec all in separate files. It also means that my specs and keys can be broken inadvertently by a refactor of those namespaces, so if the specs ever move to some other namespace, my code is broken.

a) the only thing that will work in the spec registry is sufficiently qualified ("long") namespaces b) what you want to type in your code is something short (an alias, "short" name) c) existing aliases give you exactly this feature, with the constraint that the aliased qualifier must be an actual namespace d) the thing we're going to add is the ability to do c but without that constraint (actually api still in flux)

when you say "refactoring", I hear "breaking stuff"

if you don't like stuff broken, don't break stuff

Well, since the spec registry is global, and keys outlive an app, I'd rather not couple them to some particular code namespace.

So with c without the constraint, I would do:

(ns foo.bar
  (:require [com.org.my-app.specs]
            [com.org.some-dep.specs]))

(alias 'name 'com.org.my-app.name)
(alias 'other-name 'com.org.some-dep.name)

(defn name->other-type-of-name
  [name]
  {::other-name/name (str (::name/first-name) "." (::name/last-name))})

(s/fdef name->other-type-of-name
  :args (s/cat :name ::name/name)
  :ret ::other-name/name)

(alias 'name 'com.org.my-app.name)
(alias 'user 'com.org.my-app.user)
(alias 'car 'com.org.my-app.car)
(alias 'etc  'com.org.my-app.etc)

So that last issue is why when I alias, I'd like to be able to refer to the "parent namespace" like <http://com.org|com.org>.my-app as well as the child namespaces like: com.org.my-app.name. I can still do it with c like so:

(alias 'my-app 'com.org.my-app)
(alias 'name 'com.org.my-app.name)
(alias 'user 'com.org.my-app.user)
(alias 'car 'com.org.my-app.car)
(alias 'etc  'com.org.my-app.etc)

It ends up very similar to Java honestly, with how it has a package.class/field. Basically, in practice, I've felt like I needed this scheme for my specs and my keys as well: context.entity/key

So I think of it as:

(alias '[some-context :as context :refer [entity1 entity2 entity3]])

it seems like it's impossible at that point to have any idea what that actual keyword is

(obviously it's possible, but it would require walking through several distinct mappings to get there)

I have not seen any other cases where someone was taking aliases to this degree of phased construction

Well, most people stopped using them, and instead hand type: :my-app.entity/key

I see that a lot: :cool-app.user/name

And :cool-app/user or sometimes: :cool-app.user/user depending on convention, though latter means you can't have the map and the key inside be named the same like in my ::name map with key ::name

I generally see people using a relatively small number of qualifiers for specs. it could be that that's because it's hard otherwise, but I did actually survey a large number of uses of alias / create-ns / and similar things on github to see what was out in the wild.

As far as I'm concerned, anything in a library that should be combined with other code, should use spec names that match actual namespaces, or at least fully-qualified names that "match" similar namespaces in the library. The whole point of qualified keywords in specs is that they shouldn't conflict with other code.

I've done the same, because it was too hard personally. You either go: :app.entity/key or even lazier: :app/key and then your keys are called: :app/entity-key. And you forget trying to have a full URI like <http://com.org|com.org> and hope there won't be app name clashes.

You can easily use short names just within your own code (modulo not conflicting with obvious library names -- but if libraries as using properly qualified names, that won't be an issue).

I think you're just making life harder for yourself (and you know my opinion on this already I suspect 🙂 )

I mean, as soon as I say :: people respond with don't use ::, I don't use it, etc. There's a reason for that

It is a problem when speccing your domain model though. Data that will outlive your code over time.

<http://com.org|com.org> is a straw man.

Haha, I mean replace org with the name of your org: com.worldsingles.user/id

A few people say "don't use ::"

I mean for me, I just fully qualified names in specs most of the time. I can't remember anything and then when I look at the code next, it's explicit. most code using the data is transforming it (not constructing it) and then I use :foo.bar/keys in destructuring or whatever and that covers a lot of places where I'm actually typing those namespaces.

The thing with :: is the same as dynamic vars. People don't realize that your data escapes the scope of your namespace. I've had multiple devs on my team make this mistake. They use :: in their specs, and thus their keys, and then don't realize now when you go to the DB, or return to the client, that namespace is the key's namespace as well. And maybe the spec started in: com.org.app.api. And in the future there is a service rewrite, in a new package of a different app name, or api was a bad place to put the spec cause now there are many APIs using it, and you need to move it out to prevent a circular dependency, but now it changes the key and breaks your clients (has happened to us)

I don't think that's a problem I can fix :)

Are you using Datomic?

@alexmiller When you say you use: :foo.bar/keys what do you make foo and bar equal too? Do you purposely try to find a shorter name then your application namespace? Is bar ever the entity name? Or do you do :foo.bar/entity-key ?

"Do you purposely try to find a shorter name" - generally, no

Qualification of keywords is about how unique you need the names to be.

if relevant, I think entity would be part of the qualifier

Not using Datomic no. Even without a DB though:

(ns com.my-company.my-service.api1)

(s/def ::user (s/keys :req [::id ::name ::email]))

(defn api1
  [input-request]
  {::id "123" ::name "John" ::email "<mailto:john@gmail.com|john@gmail.com>"})

Your refactoring was wrong then.

As Alex says, if you don't want things to break, stop breaking them.

The database doesn't care about namespace qualifiers.

Yes it was, but the language kinds of make you prone to it. Like at first :: pretends to be this nice convenience, but it turns out that its really inconvenient in a non toy example.

So you'd be much better doing:

(ns com.my-company.my-service.api1)

(s/def ::user (s/keys :req [::id ::name ::email]))

(defn api1
  [input-request]
  {:com.my-company.my-service/id "123"
   :com.my-company.my-service/name "John"
   :com.my-company.my-service/email "<mailto:john@gmail.com|john@gmail.com>"})

Those are real ugly in destructuring code as well

like #:com.my-company.my-service{:id "123" :name "John" :email "<mailto:john@gmail.com|john@gmail.com>"} ?

and like (let [:com.my-company.my-service/keys [id name email] ...)

Ya, in a toy example as well, until your payload returns a map of user + item keys mixed in, now you can't map alias both of them.

yes you can

Can you?

Yes.

use 2 :...keys

and both of those also support ::alias/ syntax too

I have no problem with :: (just for the record).

(with the pesky constraint that the alias has to be a real namespace)

Hum, ok I didn't know that. So I just prepend a number to it?

I'm perfectly happy to use ::alias/key for the shorter name.

no, I was just you could use two different :http://some.name/keys in the same destructuring map

{::foo/keys [a b c] ::bar/keys [b c d]}

^^

for a map {::foo/a ... ::foo/b ... ::foo/c ... ::bar/b ... ::bar/c ... ::bar/d ...}

Well, ok, the way I use namespaces on key is like so. My entity specs are keyed on: :unique-namespace/entity and my entity fields are keyed: :unique-namespace.entity/key. So at the end of the day, I just need a way to make unique-namespace shorter, because to make it unique I make it really long as I follow the format: <http://com.org.app|com.org.app>

That's my problem I'm looking a solution for

I think aliases are the solution to most of that

So imagine I have:

(s/def :com.my-company.my-service/user
  (s/keys :req [:com.my-company.my-service.user/id]
                :com.my-company.my-service.user/name
                :com.my-company.my-service.user/address
                :com.my-company.my-service.user/email
                :com.my-company.my-service.user/dob]))

Aliases.

(alias 's 'com.my-company.my-service)
(alias 'u 'com.my-company.my-service.user)
(s/def ::s/user
  (s/keys :req [::u/id]
                ::u/name
                ::u/address
                ::u/email
                ::u/dob]))

although tbh, I'm perfectly fine with the original :)

So like this?

(alias 'my-service 'com.my-company.my-service)
(alias 'user 'com.my-company.my-service.user)

(s/def ::my-service/user
  (s/keys :req [::user/id]
                ::user/name
                ::user/address
                ::user/email
                ::user/dob]))

as I said, yes

g'night all, stepping away

Ya, this is fine (assuming if they are not real namespaces for those alias will still work). Its just when I started using it in my app like that, the top of my namespaces started looking like Java import statements, they became huge, like 20 lines long, because I have big namespaces that use a lot of entities, so I was just looking for a shorter way to define those aliases. Maybe I've become allergic to verbosity since I moved away from Java 😛, but it was a sore point on my eyes.

Thanks Alex, much much appreciated. Have a good night.

And thanks Sean as well for the input

That’s a good point, thanks! I guess it is not too far of to assume, that there might be multiple classloaders at work when connecting Cider to a REPL… :thinking_face: