This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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)
- # crux (17)
- # cursive (5)
- # datomic (12)
- # emacs (41)
- # 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)
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.
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.implnamespace, 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
@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
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
requireclauses, 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
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
oh, hmm, maybe i'm confused... maybe it's ok on node, and it's just .cljc on jvm that's a problem
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)