[UPHPU] $GLOBALS and global best practices

Sean Thayne sean at skyseek.com
Tue Nov 8 09:23:48 MST 2011


Chaining would work. Like so.

$dbName = Settings::getInstance()->dbName;

or

$dbName = Settings::getInstance()->getDbName();

And yes you could use magic methods on the return singleton. Because at
that point it is a just like any other object. Zend Framework uses the
Singleton pattern a little bit. But mostly it's a non-php technique. Used a
lot in the Java world and recently a lot in Actionscript 3.0.

They usually also include a resetInstance() static function that just sets
the instance back to null. like so

public static function resetInstance()
{
     self::$_instance = null;
}

I've recently started using it and it's quite handy. Also with the new
static keyword (PHP 5.3+) You can use the word static instead of self.
Which will protected your instances if your extending. So you could have a
SingletonBase class that your settings class would extend. And you could
have 10 classes extending that SingletonBase.

With the old self:: style it wouldn't work. It would only allow one class
(the first called class) to store the instance in the parent class. With
the new static:: style it would store the instance separately and work
perfecto!

~Sean

<http://www.skyseek.com>
class *Sean_Thayne*
    extends Developer {
        public $skype = "sthayne23";
        public $gTalk = "sean at skyseek.com";
        public $url   = "www.skyseek.com";
}



On Tue, Nov 8, 2011 at 8:38 AM, Mac Newbold <mac at macnewbold.com> wrote:

> That looks like a nice way to do things - does something like that
> play nice with chaining? For example, say instead of getInstance() I
> simply called the method get(), then did this:
>
> $url = Settings::get->url;
> or perhaps
> $url = Settings::get()->url;
>
> If get() returns an object, then using -> on it would mean it would
> apply magic methods like __get() or __call(), since that part isn't a
> static access. Is that right?
>
> With regards to the messages about security and register globals and
> running extract etc on the superglobal arrays like $_POST or
> $_REQUEST, that is beyond what the original question was asking. It
> specifically mentioned using $GLOBALS['foo'] or "global $foo;" to
> access a variable from global scope. In general neither of those have
> major security implications since global variables don't come straight
> from an untrusted source unless you're doing something else bad
> (register globals/extract).
>
> Thanks and thanks in advance to everyone who is participating in the
> discussion, I have found it very helpful.
>
> Mac
>
>
> On Mon, Nov 7, 2011 at 6:23 PM, Sean Thayne <sean at skyseek.com> wrote:
> > class Settings
> > {
> >    protected $_instance;
> >
> >    public static function getInstance()
> >    {
> >        if(!self::$_instance)
> >              self::$_instance = new Settings()
> >
> >        return self::$_instance;
> >    }
> > }
> >
> >
> > Random portion of code...
> >
> > $settings = Settings::getInstance();
> >
> >
> > Sorry, did this on my phone. But this is the way to do singletons in PHP
> ;)
> >
> >
> > - Sean Thayne
> >
> > On Nov 7, 2011, at 3:12 PM, Steve Meyers <steve-uphpu at spamwiz.com>
> wrote:
> >
> >> On 11/7/11 3:05 PM, Daniel C. wrote:
> >>> Not necessarily.  The old import() function appears to be gone (thank
> >>> goodness) but we still have import_request_variables() and extract()
> >>> which appear somewhat better than import() but could still potentially
> >>> land you in the same boat:
> >>>
> >>> http://us.php.net/manual/en/function.import-request-variables.php
> >>> http://us.php.net/manual/en/function.extract.php
> >>
> >> Yes, but we're still operating under the assumption that security
> >> doesn't matter, since you're importing arbitrary variables into your
> >> namespace.
> >>
> >> Steve
> >>
> >> _______________________________________________
> >>
> >> UPHPU mailing list
> >> UPHPU at uphpu.org
> >> http://uphpu.org/mailman/listinfo/uphpu
> >> IRC: #uphpu on irc.freenode.net
> >
> > _______________________________________________
> >
> > UPHPU mailing list
> > UPHPU at uphpu.org
> > http://uphpu.org/mailman/listinfo/uphpu
> > IRC: #uphpu on irc.freenode.net
> >
>
>
>
> --
> Mac Newbold
> mac at macnewbold.com
> 801-694-6334
>


More information about the UPHPU mailing list