Re: [ANN] com.walmartlabs/schematic 1.3.0

2020-05-26 Thread Howard Lewis Ship 
 The :sc/create-fn is passed configuration of the component, but not its
dependencies, that comes later. This can often be a map->Record function in
a namespace.  Or, it can be a custom application that validates the
configuration (I use spec) and then calls map->Record.  Component will
later assign dependencies and invoke the start method, which is another
reasonable place to do validation.
.
Of course, your rec9rd may not implement Lifecycle, you may not even need a
record type.  I prefer to avoid records and protocols for my components,
wherever possible.  I'm fine with the component being a simple map, and
doing some destructuring to get at config and dependencies from simple
functions passed the component.

On Sat, May 23, 2020 at 5:47 AM Matching Socks  wrote:

> Sierra's Component README illustrates factory functions that take a
> complete static configuration at once, followed up by injections.  But,
> really, it's none of Component's concern how you work a Lifecycle thing
> into shape for Component to assoc the injections and start it.
>
> In Schematic, sc/create-fn takes a single map as a parameter, but I didn't
> see the README stating what's in the map.  It seems to me that Schematic
> would be free to include all static configuration (i.e., everything except
> other Lifecycle things), or to provide an empty map and assoc the static
> elements piecemeal along with other Lifecycle things, or anything in
> between.
>
> The question came to mind because I sometimes wonder where it was intended
> that Components validate their configuration.  Of course, it hinges on how
> the wiring-up is done.  If you code it yourself, you can use the factory
> function (and refrain from assoc), so the factory function can check
> parameters, which is nice because the resulting Exception does not tie up
> your Emacs with 100 gigabytes of Component fallout.  On the other hand, if
> you must code for the general case, you validate stuff only in the start
> method.
>
> What do you recommend?
>
>> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clojure@googlegroups.com
> Note that posts from new members are moderated - please be patient with
> your first post.
> To unsubscribe from this group, send email to
> clojure+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en
> ---
> You received this message because you are subscribed to the Google Groups
> "Clojure" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to clojure+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/clojure/9522140a-a329-41b8-92ed-5a1eececc6c3%40googlegroups.com
> 
> .
>


-- 
Howard M. Lewis Ship

Senior Mobile Developer at Walmart Labs

(971) 678-5210
http://lewisship.net 
@hlship

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/CACd-vsPNckMbYfA7nWkxT3DO41ztB-DsRQP-OZTZ2fxoAq1-nw%40mail.gmail.com.

bit-wise operators for bigint in Clojure

2020-05-26 Thread Harmon Nine 
Hello.

I noticed a post about this from 2013, so doing a bump.

The bit-wise operators appear to be supported for 'bigint' in 
ClojureScript, but not in Clojure.  Is support for these operations on 
'bigint' in Clojure a future enhancement?

Thanks :)
-- Harmon

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/4b6e3f5e-c70c-404a-9348-8117a4b32db8%40googlegroups.com.

Re: Optimizaton for finding the next key in a sorted-map

2020-05-26 Thread Harmon Nine 
Thanks very much for your responses. :)  'subseq' looks like it will do 
what's needed.
-- Harmon

On Monday, May 25, 2020 at 4:47:58 PM UTC-5, Harmon Nine wrote:
>
> Is there an optimization for sorted-maps that, when you have a given key 
> in the map, you can get the next key in O(log n) time?
>
> Given "compare" is the boolean function on which the sorted-map is based, 
> the following code will get the next-key given a current-key:
>
> (defn get-next-key [my-map current-key]
>   (first (filter #(compare current-key %) (keys my-map
>
>
> In the worst case, this would take O(n) time, as the "keys" function would 
> iterate through the n keys of the map.
>
> However, if it could be detected that the the filter is using the 
> "compare" function on which the map is based, this could speed up the 
> search:  the "current-key" could be found first and iteration could start 
> from there.  Then the "first" function could cut the search short, 
> resulting in worst-case O(log n) time to get the next key (given the 
> sorted-map is based on a tree).
>
>
> Does such an optimization exist?  If not, is there an means of getting the 
> next-key in a sorted-map given a current-key that is better than O(n)?
>
> Thanks :)
> -- Harmon
>

-- 
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/clojure/afb7e96d-9573-487c-8244-c5d0e781e21a%40googlegroups.com.