Topic: usergroup permissions

[roopurt18]

I recommend using named constants to represent the values of your permissions and not sticking $perm ^ 2 all over the place.  Also, hex is more convenient as you add more permissions.  You might know the value of 2^11 or 2^12 off the top of your head, but after that you're gonna need a calculator.  Not to mention when you look at the code later you're going to go, "What the Hell does $perm ^ 2197987252197 do again?"

[Jenk]

Constants break encapsulation.

Not to mention my example, was merely nothing but that... an example.

For a real world example taken from a class:

Code: [Select]

<?php

public function checkPermision($perm)
{
    return (bool) $this->_permissions ^ $perm;
}

?>
Hex is not more convinient, it's less readable.

It's not hard to read.. 1, 2, 4, 8, 16, 32, 64.. etc.

[roopurt18]

Like I said, the first 12 or so are not difficult to read.  But what about when you get up to your 16th or 21st permission?

Constants do not break encapsulation.  It is much easier 6 months later to read:

Code: [Select]

if($perm & _MOD_FORUMS){
}

than

Code: [Select]

if( $perm & 2097152 ){
}

Not to mention repeatedly typing 2097152 through out your code, what if you fat finger an 8 instead of a 7?  It will be very hard to catch.

Use constants.

[Jenk]

You need to learn what encapsulation is, constants most definitely do break it.

[azuka]

Do we have to argue about constants breaking encapsulation? What if [using PHP 5's features] you create a class with a static array and build static functions that allow you to add and retrieve permission 'constants' ie array keys? Everyone decides what's best for him and works with it.

As for the tutorial, I do understand binary and hex but never thought of the bitwise operators this way. Thanks for the tutorial. Now I know just what to do to implement a permission-based system.

[roopurt18]

Le sigh, this is what I think of when you say encapsulation:
http://en.wikipedia.org/wiki/Information_hiding

Please explain to me how this breaks the concept of encapsulation:

Code: [Select]

<?php
  // NPermissions.php
  // a simple example of a permission system

  // define our permission constants
  define( '_PERM_MOD_THREAD',     0x00000001 );
  define( '_PERM_MOV_THREAD',     0x00000002 );
  define( '_PERM_DEL_THREAD',     0x00000004 );
  define( '_PERM_BAN_USER',       0x00000008 );
  define( '_PERM_UNBAN_USER',     0x00000010 );
  // more constants would follow depending on the module

  // In this example, I'm going to define a class that will not be instantiated.
  // Instead, the class is being used to create a namespace.
  // The assumption for the functions within the class is that the user
  // permissions are loaded from a DB elsewhere in the program.  The first
  // param of the functions is this value, named $user_perms

  class NPermissions{
    // $user_perms - current user permissions
    // RETURN: true if user has permission, false otherwise
    function Can_ModThread($user_perms){
      return $user_perms & _PERM_MOD_THREAD;
    }

    // $user_perms - current user permissions
    // Update user's permissions to allow modding of a thread
    function Set_ModThread($user_perms){
      return $user_perms | _PERM_MOD_THREAD;
    }

    // $user_perms - current user permissions
    // Update user's permissions to not allow thread modding
    function Rem_ModThread($user_perms){
      return $user_perms & ~_PERM_MOD_THREAD;
    }

    // You would continue in this manner for each of your permissions
    // and possibly provide a few more utility functions as the case may
    // be.
  }
?>


Code: [Select]

<?php
  // AnotherFile.php
  // Meanwhile, in another part of the city...
  require_once('NPermissions.php');

  // Build our forums
  $Posts = GetForumPosts();
  if(is_array($Posts) && count($Posts)){
    foreach($Posts as $Post){
      // .. some code
      if(NPermissions::Can_ModThread($User->GetPerms())){
        $html .= Link_ModThread();
      }
      // .. some more code
    }
  }
?>

I have to say that's pretty neat, simple, and easy to maintain.  6 months later when you do need to change the implementation, you can update the constants, do away with the constants, or whatever you want.  Just as long as you keep the interface the same, nothing else in the program breaks.

Is this not what encapsulation is?  If this fits your definition of encapsulation, I would be curious how the constants are breaking it.  If it's not, I'd love for you to clarify.

[redbullmarky]

guys guys - back on topic please  the topic of encapsulation seems very irrelevent to the objective, as it's not ESSENTIAL to obey these 'rules' for what newb first asked. (although i'm with roopurt anyway a bit actually on this one. the idea of not using global constants or functions as it breaks 'encapsulation' seems slightly contradicted by using php's own built in functions, constants, etc.)

i'm following this topic myself as i'm keen to find out more - so would be good if the initial question got answered without over complication 

[Jenk]

Le sigh, this is what I think of when you say encapsulation:
http://en.wikipedia.org/wiki/Information_hiding

Please explain to me how this breaks the concept of encapsulation:

Code: [Select]

<?php
  // NPermissions.php
  // a simple example of a permission system

  // define our permission constants
  define( '_PERM_MOD_THREAD',     0x00000001 );
  define( '_PERM_MOV_THREAD',     0x00000002 );
  define( '_PERM_DEL_THREAD',     0x00000004 );
  define( '_PERM_BAN_USER',       0x00000008 );
  define( '_PERM_UNBAN_USER',     0x00000010 );
  // more constants would follow depending on the module

  // In this example, I'm going to define a class that will not be instantiated.
  // Instead, the class is being used to create a namespace.
  // The assumption for the functions within the class is that the user
  // permissions are loaded from a DB elsewhere in the program.  The first
  // param of the functions is this value, named $user_perms

  class NPermissions{
    // $user_perms - current user permissions
    // RETURN: true if user has permission, false otherwise
    function Can_ModThread($user_perms){
      return $user_perms & _PERM_MOD_THREAD;
    }

    // $user_perms - current user permissions
    // Update user's permissions to allow modding of a thread
    function Set_ModThread($user_perms){
      return $user_perms | _PERM_MOD_THREAD;
    }

    // $user_perms - current user permissions
    // Update user's permissions to not allow thread modding
    function Rem_ModThread($user_perms){
      return $user_perms & ~_PERM_MOD_THREAD;
    }

    // You would continue in this manner for each of your permissions
    // and possibly provide a few more utility functions as the case may
    // be.
  }
?>


Code: [Select]

<?php
  // AnotherFile.php
  // Meanwhile, in another part of the city...
  require_once('NPermissions.php');

  // Build our forums
  $Posts = GetForumPosts();
  if(is_array($Posts) && count($Posts)){
    foreach($Posts as $Post){
      // .. some code
      if(NPermissions::Can_ModThread($User->GetPerms())){
        $html .= Link_ModThread();
      }
      // .. some more code
    }
  }
?>

I have to say that's pretty neat, simple, and easy to maintain.  6 months later when you do need to change the implementation, you can update the constants, do away with the constants, or whatever you want.  Just as long as you keep the interface the same, nothing else in the program breaks.

Is this not what encapsulation is?  If this fits your definition of encapsulation, I would be curious how the constants are breaking it.  If it's not, I'd love for you to clarify.

The constants are references to information outside of the 'capsule' that is a module.. thus: encapsualtion broken. Hard to understand?

[roopurt18]

So you're saying if you replace the constants with literals it makes all the difference?  It would be the same thing.

The reality is every single, separate module needs to define it's own permission constants that can be imported / referenced by a central controller.  If you are designing a modular site with forums and photo galleries, each of those modules is likely to have it's own permissions.  It is impossible for the controller to store those preferences within the same 16, 32, ..., n-bit field as the modules will step on each other.

The reality is that every single module will need to define it's own permission system to be used only within that module.

Every module will also need to provide a mechanism, designed by the controller, of exporting those preferences so that the controller, and not the module, can set preferences up for specific users or groups of users.

Encapsulation is not broken.  The forum module's constants only exist within that module, the photo gallery module's constants only exist within that module, etc.  The only thing the controller ever needs to know is that this particular user logged in right now has a forum permission of 0xA0F2E0D8 and a photo gallery permission of 0x000013AB

When did I ever say that all constants across all modules will all be placed in some central file?  The situation called for a simple explanation of how bitwise operators could be used to pack multiple values into a single field.

[Jenk]

Where did I specify "literals instead of constants"?

Encapsulation is broken. Re-read the link you posted - the first paragraph says it all.

You are bypassing all interfaces to your class, so you can stop mentioning "it's part of the interface"

[redbullmarky]

chaps - please take note of the original question. whilst this is all good, and i'm picking stuff up from the argument that i didnt know before, the arguments of hex vs dec, encapsulation vs constants, etc are not gonna help the OP.

you both know your stuff - that's pretty obvious - but can you possibly stick to the topic and present a solution rather than a "best practice" argument?

cheers

[roopurt18]

Don't have to use hex, can stick with decimal..

Code: [Select]

<?php

if (!($perm ^ 2))
{
    $perm = $perm | 2;
}

?>

2 looks like a literal to me.

redbull, it would appear that the original question has been answered and that the topic has been changed to, "How do we design a system that can handle not only permissions for a forums module, but any other module we decide to add in the future?"

[Barand]

@Roopurt & Jenk

I agree with redbull. Cut out the irrelevant arguments, as far as the topic concerned, or I'll knock you heads together and close the thread. If you want to argue the point ad nauseam, do it in the miscellaneous forum.

[Jenk]

Don't have to use hex, can stick with decimal..

Code: [Select]

<?php

if (!($perm ^ 2))
{
    $perm = $perm | 2;
}

?>

2 looks like a literal to me.

redbull, it would appear that the original question has been answered and that the topic has been changed to, "How do we design a system that can handle not only permissions for a forums module, but any other module we decide to add in the future?"

Nice of you to ignore my reply after that

I'm done.

[VBAssassin]

Constants break encapsulation.

Not always...

Code: [Select]

<?php
    
    class messages {
        
        const TYPE_ERROR = 1;
        const TYPE_CONFIRM = 2;
        
        function add_message($message, $type = TYPE_ERROR) {
            
        }
    }
    
    //normal use
    $message = new messages();
    $message->add_message("Well done!", messages::TYPE_CONFIRM);
    $message->add_message("Warning though, don't do this again", messages::TYPE_ERROR);
    
?>
Source: http://www.coderprofile.com/networks/discussion-forum/1694/is-there-a-name-for-this

Kind regards,
Scott