@kenny It definitely is

can you give an example of what you are wanting to do?

you can write a macro that does something "on the fly" but given it's a macro, the fly is the time that the macro is expanded, which is part of compiling the code

which means you can compile new code as part of your algorithm (aka eval) or find something else equivalent to what the macro does

expect other devs to be very suspicious of code that uses eval

also probably worth mentioning that RH has talked about the utility of late binding / dynamic extension, in the form of using multimethods or protocols instead of case / cond / match macros; if you do this his way the problem solves itself (but you lose the pretty match macro)

Yeah, I need the things the match macro provides.

slightly unrelated

i was trying to use the tupelo library

it pulls a lot of deps

esp. considering i was just using it for map-keys

are there any more lightweight util libs people use?

@emccue useful is decent https://github.com/clj-commons/useful

it's actively maintained, and doesn't have a huge dep tree

also the quality of the code itself is well above the average baseline for clojure libs last I checked

@emccue I think map-keys and map-vals are under consideration for core at some point (maybe 1.11)? I think I read that somewhere.

thats cool to know

If you are using CLI/`deps.edn` and want those functions with no deps, use https://gist.github.com/seancorfield/6e8dd10799e9cc7527da5510c739e52f

(yes, you can have a multi-file gist as a git dependency in deps.edn! Isn't that cool?)

unrelated and possibly simple question

i can't seem to find a (test.check.generators/repeatedly call-me)

not sure if that is on pourpose

that would do what?

http://clojure.github.io/test.check/clojure.test.check.generators.html -- no such function?

keep calling a function like (repeatedly) was what i was looking for

https://clojuredocs.org/clojure.core/repeatedly

test.check generators are designed to be the only source of novelty in generated values (not arbitrary other functions) - this has several purposes. First, it allows the generator to use the same seed and generate the identical values. Second, it allows the generator to control how values are "shrunk" in the case of a failure to a simpler failing value.

@emccue Depending on what you're trying to do, I suspect you want fmap over a known set of values?

i have a function right now that just shuffles a coll and picks out values

its not a blocker, i just wanted to confirm that its not there

and i wasn't missing anything

kinda curious how shrinking is done actually, so im going to read that

There's a shuffle generator. So maybe fmap first over that?

(defn random-tile
  "Generates a random tile"
  []
  (let [shuffled-ports (shuffle tile-ports)
        pairs (mapcat (juxt vec (comp vec reverse))
                      (partition 2 shuffled-ports))]
    (into {} pairs)))

(def tile-generator
  (gen/fmap
    (fn [shuffled-ports]
      (let [pairs (mapcat (juxt vec (comp vec reverse))
                          (partition 2 shuffled-ports))]
        (into {} pairs)))
    (gen/shuffle tile-ports)))

(defn random-tile
  "Generates a random tile"
  []
  (gen/sample tile-generator 1))

went from top to bottom

its a wierd case so its okay

if you can enumerate all possible tiles, I would just use (s/gen the-set-of-tiles)

I think i can actually

thats alot less hacky

since all of the specs know how to generate already, it's often much easier to build a simple spec, and use its generator

or use (s/gen (s/tuple ...)) then gen/fmap or gen/bind over that

Hello! I want to 1. extract a thing (a person) from a collection, 2. verify that it exists and passes a test (`:alive`), 3. bind it for future use. Is there a better way to do this (extraction + test yet returning the thing, not the boolean result of the test fn) then

(if-let [jon ((fn [person] (when (:alive person) person))
              (get people :jon))]
  jon)

(if-let [[jon] (filter :alive
                  [(get people :jon)]
  jon)

You could do

(when (get-in people [:jon :alive])
  (get people :jon))

If I have an instance of a class, and I'd like that instance to extend a protocol without affecting all instances, is that possible?

You probably could via metadata if the protocol supports it: https://clojure.org/reference/protocols#_extend_via_metadata

Do all objects support metadata? I didn't think they did

only if they implement IMeta

Is it possible to make alias in deps that enables other aliases. So for instance if I have a tool like Cloverage which is run through alias cloverage, I'd like to always run it with dev and test alias enabled

not sure the best channel to ask this in, but is anyone interacting with stripe from their clojure project? looks like stripe-clojure listed under “other” on the stripe site hasn’t been touched in ~5years

@dominicm I've seen a to-x sort of pattern for this recently

(defprotocol Bird
  (fly* [_]))

(defprotocol ToBird
  (to-bird [_]))

(defn fly [birdlike]
  (if (satisfies? Bird birdlike)
    (fly* birdlike)
    (fly* (to-bird birdlike))))

so for stuff you dont want to "hard" claim you can impl to-bird

which would let the user override it - with the downside of overriding your definition

but you can also straight do a v-table like thing yourself

and store a reference to a factory function for a reify under a specific type

not sure if that helps in your specific case or not

wouldn't that be simpler as a multimethod with to-bird baked into the bird impl?

@emccue I don't think so, because another library could also soft claim this object type leading to a conflict.

hmm

what exactly is the type in this case

java DataSource is one example of something it might be.

you can keep registering proxys or the specific type behind a reify

so like

(defn make-your-datasource [existing]
  (let [impl (reify DataSource ...)]
    (do (extend-type (type impl) ...)
      impl))))

but thats... dodgey

Yeah, agree 🙂

What was the original question?

what ways would the datasources you produce be different from other data sources>

https://clojurians.slack.com/archives/C03S1KBA2/p1570699138162800

oh I missed that, and that's weird

@emccue consider something like component/integrant. You may start by just calling (.connect) or you might do (.connect) (.migrate) or any other number of things. Maybe if you're returning a data source for mysql, you need some specific contextual setup.

I'd make a new class (eg. proxy) that delegates to your instance for everything

wouldnt they have a more specific class they could customize on then?

like

(extend-type DataSource ...)
(extend-type MySqlConnClass ...)

to my knowledge the inheritance relationship still works

it sounds like this is an attempt to work around the general wisdom for protocols of "only extend a protocol to a type if you own the type or the protocol", the idea being "ok, even if I don't own the type, I own this instance of the type, so I want to extend the protocol to just this instance"

(defprotocol A (a [_]))

(extend-type java.util.List
  A
  (a [_] 1))

(extend-type java.util.ArrayList
  A
  (a [_] 2))

(a (java.util.ArrayList.))
(a (java.util.LinkedList.))

@hiredman that's exactly what I was thinking about.

Seems like the protocol is at the wrong layer - wrap the datasource in a map and extend by metadata

I would just create a type I own

Component supports extension by metadata IIRC

I think a proxy that delegates to your instance is cleaner - it's a singleton instance of a class by design, or you can make a new type if you need multiple instances

but proxy is terrible

well, a deftype you own works

But you want data not objects generally

in this case no

its a connection to a thing - its probably being used, not inspected or passed over the wire

the connection goes in the map

If the protocol is component/start stop

> Seems like the protocol is at the wrong layer - wrap the datasource in a map and extend by metadata This is pretty much what I was thinking. Eschewing the protocol altogether though. Just use a map and define the "methods" as key->var references.

That feels very weird in the context of clojure

Like, that's basically how you have to do polymorphism in something like C

I think it's an intrinsically place-oriented problem so a good solution will be place-oriented

I'm not quite understanding the reluctance to making a new type for this

Extension by metadata is a relatively new thing, but making a defrecord/deftype will definitely work

Preserving the non protocol methods requires a passthrough impl, but it's not terrible

because wrapper types have to wrap all the functionality