No, this discussion isn't about numbers versus strings. It's about Groups versus Permissions.
Hal always maintains that permissions are "atomic", implying that Groups can somehow be reduced sets of permissions. My point has always been that Groups are NOT reducible to permissions. Group Membership is an irreducible quality. Hal believes otherwise. Here is the classic example: Within my organisation, there are three Groups: Managers, Editors, Auditors. Editors can Write articles. Auditors can Read articles. Managers can Read and Write articles. John is both an Editor and an Auditor. Question: Is John a Manager? Hal's answer: Yes, John has the same permissions as a Manager, so he IS a Manager. Now that is a pure Aristotelean fallacy, just like: All Estonians live near Finland. Abba live near Finland. Therefore Abba are Estonian. So my basic point is that Group Membership tells me MORE than mere permissions, and it is a perfectly practical and *human* level at which to define your application security. The speed of BitWise operations is neither here nor there. If the speed is vital, then I will create a BitArray with each bit representing the user's membership in a particular Group. At any point in my apps, I know what Groups the current user is a member of, and I know what Groups are allowed to do what. What more could I need? That is equivalent to knowing what the users permissions are PLUS all the extra semantic information I get from knowing their Group membership. In other words, reducing Groups to Permissions is a *lossy* for of information compression, and an unnecessary one at that. Leebles. Jeff Peters wrote: > I think you've been smoking something, John. What matter which makes > more sense to someone from Esland? We're talking about permissions > here; they happen behind the scenes. And if you're worried about code, > all the roles and permissions should have reasonable variable names > anyway. The only place a coder looks at the math is inside a custom tag > > (i.e., never), so that's irrelevant. > > Math is faster than string comparison, more expandable, and easier to > manage. All that up against the specious argument that a list of > strings is easier to read than variable names (which may have exactly > the same names as your strings, if you like). > It's a slam-dunk for the numbers. > ==^================================================================ This email was sent to: [email protected] EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9 Or send an email to: [EMAIL PROTECTED] T O P I C A -- Register now to manage your mail! http://www.topica.com/partner/tag02/register ==^================================================================
