Looks good. I do have a couple questions....

1.) You reference $GLOBALS everywhere. Doesn't an object have its own scope, and thus requires that you declare the variable in the "global" class scope to use it in the functions? Rather than using individual function-specific $GLOBALS variables?

So the class would start off with: class rcRegistry { var $GLOBALS;

And then later in the functions you'd reference it with: $this->GLOBALS['rcRegistry'] ...

I may be completely off base, but that's just an impression.

Other than that, looks pretty good. Hopefully this will aid in moving away from a config file, and more to holding config info in a database which would be easier for admins to modify.

~Brett

till wrote:

Hi,

we've been toying with the idea to implement a registry to combat the "global" in RC.

Here is the first draft/idea: http://trac.roundcube.net/trac.cgi/browser/branches/devel-vnext/program/incl...

For right now the class is a bunch of static sets and gets to store and retrieve variables - optionally a namespace ($ns).

In the first step it would be an "expensive" wrapper (Singleton) around $GLOBALS, until the entire code has been ported to use it.

Further down the road, I think we should switch it to use sessions and then implement backends (e.g. database) to allow plugins to store their data or for example to make data persistent across logins, etc..

Thoughts anyone?

Cheers, Till

till wrote:

On 6/6/07, Brett Patterson brett@bpatterson.net wrote:

...

Looks good. I do have a couple questions....

1.) You reference $GLOBALS everywhere. Doesn't an object have its own scope, and thus requires that you declare the variable in the "global" class scope to use it in the functions? Rather than using individual function-specific $GLOBALS variables?

Yeah, in general you are correct - $GLOBALS is a superglobal (0) though. It's a funky replacement for the current code since it makes use of $GLOBALS too - all until we implement a backend, so it would be (for example) $this->backend[$foo] .

...

So the class would start off with: class rcRegistry { var $GLOBALS;

And then later in the functions you'd reference it with: $this->GLOBALS['rcRegistry'] ...

That always depends! ;-)

Basically, we are looking to either implement a Singleton, or static methods. If you use static methods (e.g. rcRegistry::set('foo', $bar)) we can not reference $this since it's not present in static.

Singletons have a little more runtime cost, but give you much greater flexibility for expansion later. Thinking about your "pluggable backend" idea, a singleton might be the way to go. The configuration file could declare the type or factory for the singleton registry instance, so each backend implementation just needs to extend the registry interface.

...

I may be completely off base, but that's just an impression.

Other than that, looks pretty good. Hopefully this will aid in moving away from a config file, and more to holding config info in a database which would be easier for admins to modify.

Yeah, I guess a basic configuration file is a must. But I totally agree, the more database (whatever the backend may be), the easier to manage. But it also makes you dependant on the database more and more.

Cheers, Till

0, http://de3.php.net/manual/en/language.variables.predefined.php#language.vari...