Comment by nogridbag | Hacker News Reader

Comment by nogridbag | Hacker News Reader

Parent Full thread

See my comments about Clojure.spec here:

https://news.ycombinator.com/item?id=16414942

This is all application specific, but for the types of apps I've worked on (large enterprisey OO apps) you often need various bits and pieces of domain data across different methods. So given some function, you either pass in DomainClass1, DomainClass2, DomainClass 3 (using a couple of properties of each) or you define a new class SomeSubsetOfPropertiesClass solely to call that single method. In the former case, the types do not serve as documentation for the reader as it's not clear what shape of the data is required for the function. In the latter case you're duplicating code (the properties and their types) and the class really has no meaning except as a struct to call that method.

Now that I've been working with Clojure for a little bit I find I'm able to write much more concise, testable functions and calling them is dead simple since I can work with the raw data, transforming it into the shape I need.

What you want to do is possible with a structural type system. In structural type systems, type compatibility is based on the structure of the type instead of the name (as opposed to nominal type systems).

An example in TypeScript:

     interface Named {
         name: string
     }
     
     class Person {
         name: string
         age: number
         // constructor here
     }
     
     function f(obj: Named) {
          // do something with obj.name
     }


     const joe = new Person('Joe', 25)
     
     // Compiles, even though Person has an extra `age` field
     // Person is structurally compatible with Named
     f(joe)

If you pass f() a class/object that doesn't have a `name` property of type string, the compiler would catch your error.

Interesting, except you're redefining the type of "name" in each each class by specifying "string". Also, Clojure.spec allows you to be much more precise about properties. For example, it must be a certain length, non-nil, or even match a regex (e.g. first letter starts with uppercase).

What do you mean by redefining? I'm not redefining the type of "name". If you want to get compile-time checking that `Person` implements `Named`, you can use `class Person implements Named`.

Even better than that, you don't need to use classes, you can use "normal" JS data structures. Extending the last example:

     const john = {
         name: 'John',
         age: 25
     } // No class involved

     f(john) // compiles

     const alice = {
         age: 25
         firstName: 'Alice',
         lastName: 'Jones'
     }

     f(alice) // compile-time error

Clojure.spec is cool, but I don't see how that is incompatible with static typing. You can still have libraries that check more complex properties at runtime.

EDIT: > Also, Clojure.spec allows you to be much more precise about properties. For example, it must be [...] non-nil [...]

TypeScript also handles nulls in the type system:

    function f(x: string | null) {
        if (x != null) {
              // tsc knows that inside this if, x can't be null
              return x.length 
        } else {
              console.log(x.length) // this doesn't compile, x is of type null here
        }
    }

In Clojure.spec, you spec out namespaced keywords once.

    (def email-regex #"^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,63}$")
    (s/def ::email-type (s/and string? #(re-matches email-regex %)))

    (s/def ::acctid int?)
    (s/def ::first-name string?)
    (s/def ::last-name string?)
    (s/def ::email ::email-type)

Using those keywords you can define maps which specify shapes of data:

    (s/def ::person (s/keys :req [::first-name ::last-name ::email]
                        :opt [::phone]))

Functions have their own separate specifications. Here's one that accepts a person and an acctid:

    (s/fdef add-to-account
        :args (s/cat :person ::person :acctid ::acctid)

And must be called like this:

    (add-to-account {::first-name "John" ::last-name "Smith" ::email "john@smith.com"} 12345)

If you tried calling it with an illegal argument and it's instrumented you will see an error:

    (add-to-account {::first-name "John" ::last-name "Smith" ::email "abc123"} 12345)
    
    ExceptionInfo Call to #'scratch.core/add-to-account did not conform to spec:
    In: [0 :scratch.core/email] val: "abc123" fails spec: :scratch.core/email-type at:
    [:args :person :scratch.core/email] predicate: (re-matches email-regex %)

Here's the difference. What if I have another function that just accepts an email:

    (s/fdef lookup-user
        :args (s/cat :email ::email)

And another which looks up by last name:

    (s/fdef lookup-user-by-name
        :args (s/cat :last-name ::last-name)

And now imagine if you wanted to accept either an email or last-name (notice it does not match our person spec). Attempting to use interfaces would quickly get out of control. You'd have to create an interface for every single property and extend interfaces to form arbitrary groups of properties.

This is not easy to do in say Java which is significantly different from clojure (or how typescript enforces typing). In your example it appears that you're using the name field rather than the type Named to shape data that the function will use (this is in essence ducktyping)

I am using `Named` as an argument. In structural type systems, what matters is the type structure. It's not duck typing because it's checked at compile-time.

If I change the type of "Named" to have the fields `firstName` and `lastName` of type string, accessing any other property inside `f` (like `obj.nonExisting`) or passing objects that don't have those fields.

thanks! just to clarify, how do you manage the composition of these types? Do you create a structural type per API and potentially have the "same" types repeated multiple times?

Right, but that's nothing to do with types in general, mostly just Java and friends with unimaginative type systems.

To be fair, the OO example you give just sounds like bad design. It should be entirely possible to avoid having to pass giant bundles of state between different layers of your application, and even if you can't you should be able to define interface conformances on your DomainClass objects to make it clear which of their members are actually relevant in a given case.

Absolutely it's bad OO design. Because it's very difficult to do OO right at scale. For a larger application like many I've worked on (thousands of domain classes), it's much less risky to have an anemic domain model than attempt to model a very complex domain properly. I would imagine in the Java world most applications that use ORMs tend to lean towards anemic domain models that simply mirror DB tables.

Reply on news.ycombinator.com