@larry I added bitmask permissions to
https://github.com/tuhlmann/permissions together with a set of unit tests
and a description in Readme. Please have a look if you like.

I don't think I will ever use it as I'm quiet content with the literal
approach. But it was an interesting exercise to separate concerns in order
to make the library more flexible and not more complex at the same time.

Kind Regards,
Torsten.


<adrian.med...@mail.yu.edu> schrieb am Do., 13. Okt. 2016 um 14:50 Uhr:

> My suggestion of a bitmask was just a response to a suggestion of prime
> factorization for encoding roles in an integer. I think using a set is just
> fine. The space requirements for a small set of keywords is negligible in
> the larger scheme of things. It also permits more readable code (always a
> good thing) with bits of code that need to interact with it.
>
>
> On Thursday, October 13, 2016 at 7:56:10 AM UTC-4, Torsten Uhlmann wrote:
>
> It might be premature optimization, or you could view it as a different
> approach, for a different usage scenario.
> I'm myself pretty content with the literal approach, we're using this in a
> fairly large application and haven't experienced any problems with regards
> of performance or amount of data attached to users so far.
>
> On the other hand I see these suggestions as a way to experiment with
> alternative approaches, which might as well teach me something...
>
> Stefan Kamphausen <ska...@gmail.com> schrieb am Do., 13. Okt. 2016 um
> 10:29 Uhr:
>
> Hi,
>
> Doesn't that feel like premature optimization to you, too?  Bitmasks are
> much harder to read than sets with spelled out roles and I wonder if the
> performance gain is really worth that. And it poses a limit of 64 roles.  I
> have seen several enterprise applications that had far more than 64 roles
> and/or permissions.
>
> Or am I missing something here?
>
> Just my 2ct.
>
> Kind regards,
> Stefan
>
> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
>
> To post to this group, send email to clo...@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+u...@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+u...@googlegroups.com.
>
>
> For more options, visit https://groups.google.com/d/optout.
>
> --
> 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.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to