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 = "[email protected]";
public $url = "www.skyseek.com";
}
On Tue, Nov 8, 2011 at 8:38 AM, Mac Newbold <[email protected]> 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 <[email protected]> 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 <[email protected]>
> 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
> >> [email protected]
> >> http://uphpu.org/mailman/listinfo/uphpu
> >> IRC: #uphpu on irc.freenode.net
> >
> > _______________________________________________
> >
> > UPHPU mailing list
> > [email protected]
> > http://uphpu.org/mailman/listinfo/uphpu
> > IRC: #uphpu on irc.freenode.net
> >
>
>
>
> --
> Mac Newbold
> [email protected]
> 801-694-6334
>
_______________________________________________
UPHPU mailing list
[email protected]
http://uphpu.org/mailman/listinfo/uphpu
IRC: #uphpu on irc.freenode.net
