This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-13
Channels
- # aleph (1)
- # announcements (14)
- # aws (8)
- # babashka (3)
- # beginners (49)
- # cider (6)
- # clara (7)
- # clj-kondo (58)
- # cljs-dev (17)
- # clojure (65)
- # clojure-dev (45)
- # clojure-europe (5)
- # clojure-italy (4)
- # clojure-nl (25)
- # clojure-norway (3)
- # clojure-uk (68)
- # clojurescript (10)
- # cursive (5)
- # datomic (12)
- # emacs (24)
- # fulcro (149)
- # hoplon (56)
- # kaocha (2)
- # luminus (18)
- # malli (7)
- # off-topic (12)
- # other-languages (82)
- # reagent (16)
- # reitit (7)
- # shadow-cljs (44)
- # spacemacs (4)
- # tools-deps (48)
- # xtdb (17)
Morning 😄 I've been back at work a week and I'm still thinking about going back to sleep
2/3 links I checked say today is plough Monday... That means it's time to go back to work slackers (pun unintentional, but not avoided)
Day 1 of holiday….. Planning a talk, a proposal to put in and figure out some streaming stuff.
måning
Sorry, I do try not to get too much into politics / current events on this channel, but this made me literally "lol", and I thought I would share the mirth on a cold monday morning.
Say I wanted needed to make a private field accessible using Clojure (a java class, interop stuff), any examples?
(defn private-field [obj fn-name-string]
(let [m (.. obj getClass (getDeclaredField fn-name-string))]
(. m (setAccessible true))
(. m (get obj))))
but keep in mind security policies can prevent this (if you ever want it deployed at a customer site you don’t control)
Yeah, I used to do a magic trick where i'd use this to alter the state of an interned string value, so that you could write, System.out.println("HELLO");
and it would print "GOODBYE". It was quite fun.
I didn't consider using the standard java paradigm in doing this - I was looking at clojure.reflect etc..
Would anyone be interested in volunteering to be a coach for ClojureBridge London this February? Details are here: https://www.bridgetroll.org/events/500.
interested but dates aren't ideal. the page suggests that you already have more coaches than coachees? do you still want more?
Hey! Thank you for your interest! I think we are good for this February but I'm happy you considered being a coach
It's been on my todo list for a while, but if there's no shortage of coaches then that's great!
(tangentially, the date formats on that website you linked are quite hard to read)
does anyone use a separate namespace just for keywords relating to a particular component, so that it's safe to :require
from anywhere and get namespace aliases without circular deps ?
@mccraigmccraig I am not sure I 100% understand the question, so I guess I don't. Sounds intriguing though.
just this... if you have a component with some interface fns or whatever defined in foo.thing
, you might want to to use :foo.thing/whatsit
namespaced keywords with it... over time, if your implementation expands and you get a foo.thing.impl
namespace, if that gets required by foo.thing
then it can't require [foo.thing :as t]
to get namespace alised keywords like ::t/whatsit
because there would then be a circular dependency
one solution is to never use aliases for namespaced keywords in implementations, another would be to use a namespace just for keywords like :
so you can require [
and use ::t/whatsit
maybe i'm just being thick and there are other possibilities too
@mccraigmccraig Yeah, I see what you mean. I don't do this. I think for a couple of reasons of personal principal and a couple of reasons of personal ignorance. An example of the latter is that I am not even sure I knew / realised that "requiring as" and then using the alias for the namespace keyword was even a thing. Something I would probably have expected to work, but probably wouldn't think about. On principal though, I think having foo.thing require foo.thing.impl would register as a smell to me because I don't really like a "general" namespace knowing about a "specific" one in this way. If all this stuff got too awkward I think my tendency would probably be to just put everything in foo.thing, because I am developing a view that large clojure namespaces are not too much of a problem and I am trying to resist my old urges to break everything up. clojure.core is pretty big, and that seems to be fine, so I might question why I would need the seperate impl namespace in the first place and merge it all back in... but I thinking aloud here.
no, you can't alias a namespace without requiring it afaict, although the namespace for a keyword doesn't need to exist at all - but it does if you want to alias it
this is mostly coming from a re-frame app - there's no alias
in clojurescript
It's a bit weird really because you are not at all needing to "read" the code in foo.thing there, you just want a short hand. You get the short hand by reading it, but you want the effect and not the cause.
and it's re-frame standard layout to split event-handlers, subs and views and db stuff relating to the same component into separate namespaces
yeah... we mostly have used keywords with namespaces which don't relate to a "real" namespace at all, but that brings another problem - sanitising the ns
declarations for re-frame components which refer to the subs and event-handlers of such components will remove the require
clauses, because there's never any direct reference to a thing in the namespace
hence looking at using keywords which refer to real namespace, so we would use re-frame event handlers or subs name :foo.thing/whatsit
etc
It does raise the interesting question about whether the re-frame standard layout is sensible. It's one of those "two dimensional hierarchy" problems, where you want to separate based on both component and function area. I am pretty sure I explored breaking from this convention in previous re-frame experiments and allowing myself to define the views, handlers, subs etc for a single component in a single namespace... at least where they were component specific. I am pretty sure I had a "core" namespace that defined subs etc that are used in various places (user etc), but I was just toying around.
we've done both - some of our older code has everything in a single namespace, but it sure gets unwieldy and hard to navigate after a while
Probably easiest solution is just to type the whole namespace for the keywords. Just avoid the problem of having to require the ns at all. Little extra typing, but problem disappears.
also, one re-frame ns is harder to test - subs and event-handlers don't need any react related stuff, so we can run their tests on node or even clj/jvm, but only if they are separated from the views code
yeah, you are probably right (use longform keywords)
oh, hmm, maybe i'm confused... maybe it's ok on node, and it's just .cljc on jvm that's a problem
I'm surprised cljs doesn't have alias
... I wonder why not?
there aren't any vars @seancorfield
alias
doesn't have anything to do with Vars tho'...
In Clojure we use (alias 'foo (create-ns 'foo.bar.quux))
and I see that create-ns
works in cljs... alias
is like require ... :as
so it seems a strange omission.
(but if I've learned anything about cljs over the years, it's that it has lots of small, sometimes strange, differences from clj)
i guess at some point in history it didn't make much sense to provide alias
if there was nothing for you to refer to with an aliased reference