Jump to content

Jenk

Members
  • Posts

    778
  • Joined

  • Last visited

    Never

Posts posted by Jenk

  1. E_NOTICE's:

     

    [...] Indicate that the script encountered something that could indicate an error, but could also happen in the normal course of running a script.

     

    Perhaps you could explain to me, sans E_NOTICE, how a variable which is unset is "a different case entirely from having a null value".  Afterall null was invented in order to designate absence of value. 

     

    <?php
    $foo = null;
    
    if($foo === $bar){ // no E_NOTICE for $foo, only for $bar - Jenk 3 - Patrick 0.
    echo '$foo is equal to an undefined $bar'."\n";
    }
    
    if(!isset($foo)){
    echo '$foo IS set (to null)'."\n";
    }
    ?>
    

     

    Patrick - 1 Jenk - null :-p

     

    ...

    If a variable has been unset with unset()' date=' it will no longer be set. [b']isset() will return FALSE if testing a variable that has been set to NULL.[/b] Also note that a NULL byte ("\0") is not equivalent to the PHP NULL constant.
    Jenk 4 - Patrick 0.
  2. $HTTP_RAW_POST_DATA is not always set. A different case entirely from having a null value.

     

    Hmm... you sure?

     

    <?php
    $foo = null;
    
    if($foo === $bar){
    echo 'Patrick - 1 Jenk - 0 ';
    }
    ?>
    

     

    I think that PHP initializes all variables to null unless explicitly assigned a (non null) value.

     

    Patrick

    Now turn on all errors and watch that "E_NOTICE undefined variable $bar" error message fly. Jenk 2 - Patrick 0.
  3. so basically there is absolutely no point what so ever in declaring a instance variable public. and i realize why they are meant to be private its so you cant access it directly form the instance, correct ?

    iirc it raises an E_NOTICE error when you don't declare the variables.

     

    If you want to create a value object or similar, you can declare the __set() and __get() magic methods to store data cleanly.

    <?php
    class ValueObject
    {
        private $_data = array();
    
        public function __get ($name)
        {
            if (!isset($this->_data[$name])) throw new IndexOutOfBoundsException($name . ' is not a valid member');
    
            return $this->_data[$name];
        }
    
        public function __set ($name, $val)
        {
            $this->_data[$name] = $val;
        }
    }
    
    $foo = new ValueObject;
    
    $foo->bar = 'Hello Worls!';
    
    try
    {
        echo $foo->bar;
    }
    catch (IndexOutOfBoundsException $e)
    {
        echo '$foo->bar has not been set yet!';
    }
    ?>

  4. You're trying to be insulting again. "Chill out", I'm not annoyed/angry. "Now don't get mad at me for telling it how I see it, there is not one right way unless you're a Christian and quoting the bible. Maybe you should be a little less caught up with OOD heuristics and start thinking for yourself." How utterly condescending of you.

     

    The debate isn't purely about registry vs the rest; it's about globals vs the rest.

     

    Data mapper or DAO - and infact every - object ever created only cares about the interface of another object. To extend your example of a user, dao and datamapper; none of them need to know anything about any object they relate to, other than if they fit the interface.

     

    Node path's are no more than 3 or 4 deep, at the very worst. If your node path's extend further than 3 you should really consider redesigning as a rule of thumb. Some exceptions such as ORM examples do exist. If not a registry, then your controller should be instantiating objects and passing to the sub-components. Something like:

    <?php
    class 
    {
        public function run ()
        {
            $this->_view = new View();
            $this->_view->display(new Model());
        }
    }
    ?>

    is fine. Encapsulation is not broken; the View object does not know what the Model object is, except that it fits the expected interface. The controller is doing it's job, controlling which nodes are invoked.

     

    and just adding this as I was typing the above whilst two more replies came in..

    utexas_pjm.. yes, that's also a perfectly acceptable use of the registry.

     

    "The point goes beyond the Domain Model. After posting that I realized that it was probably not the best example example of the problem. In fact, I was a bit disappointed in Jenk for not noticing and banging me down for it.  :P" I refer you to my first comment.

     

  5. Like I said, you have a fault in your design if that is the case. Why are objects calling on objects that don't need parameters, yet the object below them need parameters? Remove the middle man if that is the case.

     

    You can be witty (and trying to be insulting) and draw all the pictures you want, singleton's cause problems. Encapsulation is broken with any form of global. Why use objects if you are not going to use their interface? Might as well go back to procedural programming.

  6. Still solved by passing a registry instead..

     

    <?php
    
    $registry = new Registry;
    // add stuff to $registry here
    
    $controller = new Controller($registry);
    
    // now within the controller..
    public function doSomething()
    {
        // add more stuff to the registry here, before using the following
        $this->_child = new SomeChildClass($this->_registry)
        $this->_child->run();
    }
    
    //now within the child..
    public function run()
    {
        $this->_view = $this->_registry->at('view');
        $this->_view->setModel($this->_registy->at('model'));
        $this->_view->display();
    }
    ?>

    crappy example, but explains the concept clearly.

  7. Daniel0: that works fine if I'm accessing $ifc0nfig->MySQL outside of a class, but if I'm in another class (navi) I cant access the MySQL object or even the ifc0nfig object (without class extends). The classes are in differant files (shouldn't matter?).

     

    Jenk: Not sure if I follow you here but making $_mysql private isn't going to help at all? I want other classes to be able to access it.

    You've missed the point entirely.

     

    1. The navi object is constructed outside of your ifc0nfig class, thus not breaking encapsulation.

    2. It is not an extension, it is a parameter.

    3. You are free to pass around the navi object to other objects.

  8. There's no reason to extend one with the other in this case, they are not interrelated in such a way to make it viable. Instead, use the mysql/navi object for what it is, an object.

     

    <?php
    
    class ifc0nfig // what's with the 0 instead of o?
    {
        private $_mysql;
    
        public function __construct (navi $db)
        {
            $this->_mysql = $db;
        }
    
        public function doSomethingWithMySQL()
        {
            $this->_mysql->doSomething();
        }
    }

  9. yeah i get you now but how would i make a script that would go through like that and then check that value against another until they match and echo out what is has tried??? im now just interested lol

    You've already answered your own question..
  10. but how come if you get the md5 from the database then md5 the users input and compare they would match so you cant just use a loop to go through?

    You're asking about brute-force attacks, which of course are blatantly possible - so why even ask that question?

     

    and it's not possible to check if the nth character is correct, you must and can only compare the entire value.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.