RE: [fw-general] Zend.php proposal
From my experience in using registry style systems I've only ever used them
statically, I can't see the point for using it as an object, i.e.
$registry = new Zend_Registry();
I think from reading the above that is being proposed as an option. If I've
understood correctly, I'd strongly vote against it. The whole point of the
registry is to provide access to variables across an app from within
different classes without having to resort to global variables. If you don't
need access across classes, why bother using the registry?
I agree with Bill that:
$r = Zend_Registry::get();
Invites a level of confusion to usage.
$r = Zend_Registry::getInstance();
Is far better to understand. I've also asked a newbie developer here and I
quickly explained the getInstance functionality and how the code would look
under both circumstance. He found the method name quite understandable and
he has no idea what singleton patterns are. So I think the method name is
logical.
However, I would normally use the registry as so:
$config = Zend_Registry::get('config');
$dbname = $config-db-name;
Though I can see how accessing multiple objects stored in a registry in one
controller is easier (and less code) by using:
$r = Zend_Registry::getInstance();
$dbname = $r-config-db-name;
$bar = $r-foo-bar;
So the current proposal sounds very good to me :-)
However, I have no idea what this is for:
$foo = $r-offsetGet('foo');
best wishes,
Si
Re: [fw-general] Zend.php proposal
-- Matthew Ratzloff [EMAIL PROTECTED] wrote
(on Wednesday, 07 March 2007, 02:40 PM -0800):
In that case, we need to go back to the drawing board with components that
model simple processes like Zend_Session (Zend_Session_Namespace adds
value, but is not intuitive)
Zend_Session_Namespace may not be intuitive in terms of naming or what
it does, but the actual *usage* is incredibly simple and very intuitive:
$auth = Zend_Session_Namespace('auth');
echo $auth-name;
I personally like that notation, but I may be an OO junkie.
or the new Zend_Log class (passing a
Zend_Log_Writer_* object to the constructor could be confusing).
How is:
$log = new Zend_Log(new Zend_Log_Writer_Stream($filename));
$log-log('My error message'):
harder than:
Zend_Log::setAdapter(new Zend_Log_Adapter_File($filename));
Zend_Log::log('My error message');
?
They're almost identical in usage. And the former is *better* because I
can have a different log object for each log I want to keep, instead of
needing to pass extraneous arguments to each log action indicating which
named log I want to write to. With the new Zend_Log, I create a log for
each discrete task I want to log, and then store the object in the
registry; this is easier and more intuitive in many regards. (If you've
used Zend_Log for much, you'll know what I'm talking about.)
--
Matthew Weier O'Phinney
PHP Developer| [EMAIL PROTECTED]
Zend - The PHP Company | http://www.zend.com/
Re: [fw-general] Zend.php proposal
I think static ::get('foo') and ::set('foo', 'bar') methods are acceptable
compromises, but get() really shouldn't replace getInstance(). It
I'm OK with this.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
RE: [fw-general] Zend.php proposal
We really need to finish this discussion in order to have enough time to
implement the changes before the code-freeze. I think we're virtually
finished.
To summarize:
Zend::dump() moves to Zend_Debug::dump(). The idea of using a logger is
dropped.
Zend::VERSION and Zend::compareVersion() move to Zend_Version class.
Zend::loadClass(), loadFile(), and isReadable() move to Zend_Loader
class. Perhaps in the future we will have a Zend_FileSystem class, but
there is no proposal for that now.
Here are the methods proposed for Zend_Registry:
Zend_Registry::getInstance()
Returns the default static instance. It creates the instance if
necessary, based on the classname currently set (default
'Zend_Registry'). After you retrieve the instance, you can use it as an
ArrayObject:
$r = Zend_Registry::getInstance();
$r[$key] = $value;
Changes to the ArrayObject apply to the static instance:
Zend_Registry::get($key) is now $value
Zend_Registry::get( $key )
Returns an entry from the static registry instance based on key
specified in the argument. I propose that this _not_ return the whole
registry object when called like ::get(null). That's what getInstance()
does.
Zend_Registry::set( $key, $value )
Sets a value in the static registry.
Zend_Registry::setInstance( $registry )
Initialize the static registry instance to an object of type
Zend_Registry or a subclass. Developers don't normally need to do this;
it's done implicitly by any of the three above methods. But this method
exists in the proposed class code already, why not make it public?
Zend_Registry::setClassName( string )
Specifies the name of the class to use for the default static instance
of the registry. This is optional and it defaults to 'Zend_Registry'.
You must do this before the registry has been initialized by any of the
four above methods.
Zend_Registry::__unsetRegistry()
Sets the current static registry instance to null. This is currently
only used by unit tests, but there might be cases where you want to do
this too. For example, if you have an initialized static registry and
you need to empty it out or reset it because you want to use a different
class, you would use this method.
Regards,
Bill Karwin
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 08, 2007 9:53 AM
To: [EMAIL PROTECTED]
Cc: Zend Framework
Subject: Re: [fw-general] Zend.php proposal
I think static ::get('foo') and ::set('foo', 'bar') methods are
acceptable
compromises, but get() really shouldn't replace getInstance(). It
I'm OK with this.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
We really need to finish this discussion in order to have enough time to implement the changes before the code-freeze. I think we're virtually finished. To summarize: Looks OK to me. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
RE: [fw-general] Zend.php proposal
We really need to finish this discussion in order to have enough time to implement the changes before the code-freeze. I think we're virtually finished. To summarize: [...] Looks good to me. -Matt
Re: [fw-general] Zend.php proposal
Bill Karwin wrote: Zend_Registry::__unsetRegistry() Prob a single underscore would be better as double typically implies php-internal hook methods. All in all, This looks real good. -ralph
Re: [fw-general] Zend.php proposal
Almost seems like Zend_Registry is being designed using a mailing list thread. I thought there was supposed to be a proposal process followed by a review process then some incubator code and testing. Oops. Wait a second. we did have a proposal. It was reviewed and approved. And code was checked into the incubator. But then some deleted it. Very sad. In any event, the attached files match roughly 99% of what has been discussed on this thread. Maybe they will save someone some typing. Registry.php Description: Binary data
RE: [fw-general] Zend.php proposal
Art, the Registry.php in the incubator was moved to core over two months ago. That's from a different round of changes. Discussion is appropriate for mailing lists. I'm trying to apply the conclusions we make to the proposal here: http://framework.zend.com/wiki/display/ZFPROP/What+to+do+with+Zend.php There's prototype code for Zend_Registry in that proposal, updated to the latest conclusions that have been discussed here. Bill -Original Message- From: Art Hundiak [mailto:[EMAIL PROTECTED] Sent: Thursday, March 08, 2007 11:07 AM To: Zend Framework Subject: Re: [fw-general] Zend.php proposal Almost seems like Zend_Registry is being designed using a mailing list thread. I thought there was supposed to be a proposal process followed by a review process then some incubator code and testing. Oops. Wait a second. we did have a proposal. It was reviewed and approved. And code was checked into the incubator. But then some deleted it. Very sad. In any event, the attached files match roughly 99% of what has been discussed on this thread. Maybe they will save someone some typing.
Re: [fw-general] Zend.php proposal
Bill Karwin schreef: I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin This looks alright to me, no furhter comments :-). I'm willing to help with moving these things around, let me know if you need help. Best, -- Andries Seutens http://andries.systray.be Gecontroleerd op virussen door de JOJO Secure Gateway.
Re: [fw-general] Zend.php proposal
+1 from me Greetings Thomas I18N Team Leader - Original Message - From: Bill Karwin [EMAIL PROTECTED] To: Zend Framework fw-general@lists.zend.com Sent: Wednesday, March 07, 2007 10:20 AM Subject: [fw-general] Zend.php proposal I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin
Re: [fw-general] Zend.php proposal
Solution E sounds good to me Le mercredi 7 mars 2007, Bill Karwin a écrit : I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin -- Olivier Sirven Elma Ingénierie Informatique 3, rue d'Uzès F-75002 - Paris - France http://www.elma.fr Tel: +33-1-44882744 Fax: +33-1-44882747 Email: [EMAIL PROTECTED]
Re: [fw-general] Zend.php proposal
E is good. Would suggest that Zend::dump be moved to a Zend_Debug class instead of Zend_Log. Logging and debugging are different concepts. But it's a minor point. I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin
RE: [fw-general] Zend.php proposal
I agree, solution E sounds fine best wishes, Simon
Re: [fw-general] Zend.php proposal
I agree with Solution E.
But as mentioned in another post wouldn´t be Zend::dump be more useful (in
aspects of loggig) when it returns a string respective an array('HTML-Form'
= ... , 'FILE-Form' = ...) containing \n or br /
regards
RE: [fw-general] Zend.php proposal
I like E solution, but i like Zend/Debug.php too =) anyway, dump() method does
not matter where is. ?php ... require('Zend/Loader.php'); function
__autoload($className) {Zend_Loader::loadClass($className);}
$frontController = Zend_Controller_Front::getInstance(); ... ? And that's all.
End of backward compatibility problems. Cheers.
_
Descubre Live.com - tu mundo en línea reunido: noticias, deportes, el tiempo, y
mucho más.
http://www.live.com/getstarted
Re: [fw-general] Zend.php proposal
Major +1 on solution E, this is the right direction! Great job. Bill Karwin wrote: I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 If Solution E is acceptable, I move that we proceed with that implementation. We need to implement the change (including updating other components, unit tests, and docs) by the code-freeze or else we will live with the current Zend.php! Regards, Bill Karwin
Re: [fw-general] Zend.php proposal
Matthew Ratzloff wrote: I still like Zend_Debug (at the least, I don't feel it belongs in Zend_Log, since the concept behind it is different). Just because there would only be one method now doesn't mean there wouldn't be any in the future. For example, I can see two methods already--dump() as it exists now, and dump() as it exists in your proposal. Matthew, I agree with you here, and I think those that agree with you probably have grander plans for the future of debugging inside the Zend Framework.. For example, I've heard of concepts like breakpoints, tracing functions, etc.. I also like the idea that perhaps zend studio could interact with a developing application through Zend/Debug, perhaps it interacts with Zend/Debug and the zend-debugger.so, perhaps even the 'other' php debugger? These are a few concepts that I think once people have time, they will explore.. So at current, I don't really care where it is, I just think people should be aware that in the future, it might grow into something even more useful. Cheers, Ralph
Re: [fw-general] Zend.php proposal
It's the same difference. Either way, a custom registry is required for that use case. -Matt In the wiki it reads: Redesign Registry methods to store the singleton object as a static variable in the Zend/Registry.php class. Allow app to specify which class to use for the singleton, to allow subclassing. The way I look at it you don't have to extend Zend_Registry to use multiple instances. All it says is that if you want the ZF to use your own registry you can tell it to do so. On 3/7/07, Matthew Ratzloff [EMAIL PROTECTED] wrote: Hi Bill, I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 So if you want to have multiple registries in one application (for different areas of control), you need to extend Zend_Registry. Well... it's an edge case, so I can live with that.
RE: [fw-general] Zend.php proposal
So $registry = new Zend_Registry() will continue to work, then. That's great to hear. :-) -Matt No Matthew, you don't have to subclass to have multiple registry instances. The intention is that _if_ you use a subclass of Zend_Registry, you can specify the class name to use for the static default instance. In the old Zend.php design, the default registry was stored as a static member in the Zend.php class. But there's no reason it can't live as a static member within the Zend_Registry class instead. Zend_Registry isn't a true singleton; you can still instantiate it as an object and store the object somewhere yourself. You don't even need to use the static methods at all! But in addition to being instantiated, the class also provides a static location where you can access one default instance of a registry object through static methods, so you don't have to make a global location to store your registry instance. Also consider that a registry can store objects -- even objects of type Zend_Registry. So you can have multiple instances of Zend_Registry, each of which are stored as entries within the default Zend_Registry instance. But this is a good way to get yourself confused. :-) Regards, Bill Karwin -Original Message- From: Matthew Ratzloff [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 07, 2007 9:30 AM To: Zend Framework Subject: Re: [fw-general] Zend.php proposal It's the same difference. Either way, a custom registry is required for that use case. -Matt In the wiki it reads: Redesign Registry methods to store the singleton object as a static variable in the Zend/Registry.php class. Allow app to specify which class to use for the singleton, to allow subclassing. The way I look at it you don't have to extend Zend_Registry to use multiple instances. All it says is that if you want the ZF to use your own registry you can tell it to do so. On 3/7/07, Matthew Ratzloff [EMAIL PROTECTED] wrote: Hi Bill, I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 So if you want to have multiple registries in one application (for different areas of control), you need to extend Zend_Registry. Well... it's an edge case, so I can live with that.
Re: [fw-general] Zend.php proposal
I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 I'm not sure I understand - what I'm supposed to do now instead of Zend::dump? Also, I think that: $registry = Zend_Registry::getInstance(); $registry['key'] = 'value'; is better than: Zend::regiser(key, value) There should be some shortcuts. E.g. something like Zend_Registry::put($key, $value) and Zend_Registry::get($key) so you don't have to do getInstance each time. Also, what would become to Zend::initRegistry? Also, if we do loader class, I think it would be a good idea to interface with spl_autoload etc. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
$registry = Zend_Registry::getInstance(); $registry['key'] = 'value'; The current Zend.php class supports this now, so only the names of the class and methods have changed in C/E. Regarding static accessors for the special instance stored in a static variable, they can easily be added using a subclass of Zend_Registry. I'm in favor of keeping Zend_Registry as light as possible. Cheers, Gavin Stanislav Malyshev wrote: I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). http://framework.zend.com/wiki/x/j1 I'm not sure I understand - what I'm supposed to do now instead of Zend::dump? Also, I think that: $registry = Zend_Registry::getInstance(); $registry['key'] = 'value'; is better than: Zend::regiser(key, value) There should be some shortcuts. E.g. something like Zend_Registry::put($key, $value) and Zend_Registry::get($key) so you don't have to do getInstance each time. Also, what would become to Zend::initRegistry? Also, if we do loader class, I think it would be a good idea to interface with spl_autoload etc.
RE: [fw-general] Zend.php proposal
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
I'm not sure I understand - what I'm supposed to do now instead of
Zend::dump?
I had in mind using the new Zend_Log class. First set up a logger:
$log = new Zend_Log(new Zend_Log_Writer_Debug('php://stdout'));
You only have to set that up once, if you store the $log object
somewhere that is accessible throughout your app.
Then you can dump a variable anytime like this:
$log-debug( $myObject );
$registry = Zend_Registry::getInstance();
$registry['key'] = 'value';
is better than:
Zend::regiser(key, value)
Yes, I agree. I always have to think for a split-second about which one
sets and which one gets. :-) I will be happy to see register() and
registry() become deprecated.
There should be some shortcuts. E.g. something like
Zend_Registry::put($key, $value) and Zend_Registry::get($key) so you
don't have to do getInstance each time.
You don't have to use getInstance() each time. If you have an object of
type Zend_Registry, just use the array notation. You are not required
to use the default static instance of the registry. You can create an
instance of a Zend_Registry object and put it anywhere you want -- even
a global variable:
// in bootstrap:
$globalReg = new Zend_Registry();
// anywhere in application:
$globalReg['key'] = 'value';
Also, what would become to Zend::initRegistry?
Also, if we do loader class, I think it would be a good idea to
interface with spl_autoload etc.
Yes, Zend_Loader would be a natural place to implement an autoload
callback function.
Regards,
Bill Karwin
Re: [fw-general] Zend.php proposal
Regarding static accessors for the special instance stored in a static variable, they can easily be added using a subclass of Zend_Registry. I'm in favor of keeping Zend_Registry as light as possible. Everything can be added. But we want our classes to be simple to use as they are, not some assembly required, do we? So why not make extra step towards the user and give people tools for working conveniently with their classes and not have everybody to rewrite these additions by themselves each time? That's would be the scenario 90% of the users would be doing anyway, so why not make it easy? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
What if we included the subclass in the box? Both the old and the new are designed to work smoothly with subclasses. Cheers, Gavin Stanislav Malyshev wrote: Regarding static accessors for the special instance stored in a static variable, they can easily be added using a subclass of Zend_Registry. I'm in favor of keeping Zend_Registry as light as possible. Everything can be added. But we want our classes to be simple to use as they are, not some assembly required, do we? So why not make extra step towards the user and give people tools for working conveniently with their classes and not have everybody to rewrite these additions by themselves each time? That's would be the scenario 90% of the users would be doing anyway, so why not make it easy?
Re: [fw-general] Zend.php proposal
I'm not sure I understand - what I'm supposed to do now instead of
Zend::dump?
I had in mind using the new Zend_Log class. First set up a logger:
$log = new Zend_Log(new Zend_Log_Writer_Debug('php://stdout'));
You only have to set that up once, if you store the $log object
somewhere that is accessible throughout your app.
Then you can dump a variable anytime like this:
$log-debug( $myObject );
I really don't think that's a good replacement for Zend::dump. I used it
for print-debugging a lot since it's better that var_dump and as easy as
var_dump. Now you propose to kill it and replace with two-stage
constructor and carrying over the object which I really don't need. It's
not simple. It's not easy. Zend::dump is *easy*, having two-level ctor
and additional object is *complex*. I don't like the direction we are
moving in - it's definitely looks like what I don't like in Java - you
have to do a lot of actions before you get result and care for a lot of
classes which you really don't want to know to do a simplest thing like
output debug value. I don't want to learn about log writers and
interfaces and loggin infrastructure and php://stdout and stuff just to
do a simple debug-print.
Yes, I agree. I always have to think for a split-second about which one
sets and which one gets. :-) I will be happy to see register() and
registry() become deprecated.
OK, make it get() and put() - but it should be *easy*. It should not
require knowing about singletons and instances. The concept of putting
and getting variable in registry is simple, so should be acting on this
concept in framework. If you want to do complex stuff (like having
multiple registries) then it can be complex, but easy actions should be
done by easy code. That's why we have SimpleXML - that's why we should
have SimpleRegistry and SimpleDump :)
You don't have to use getInstance() each time. If you have an object of
type Zend_Registry, just use the array notation. You are not required
I don't want to have object of type Zend_Registry - I want just global
access to registry, like I had with Zend::register(). How I do it with
Zend_Registry?
to use the default static instance of the registry. You can create an
I *want* to use it. Actually, in 90% of use cases I don't care it all
how many objects there are and what they are - I just want to put stuff
there and get stuff from there. I don't want to know how it is implemented.
instance of a Zend_Registry object and put it anywhere you want -- even
a global variable:
// in bootstrap:
$globalReg = new Zend_Registry();
// anywhere in application:
$globalReg['key'] = 'value';
Errr? So we went all this long way with registry - only to get back to
global variables? If I wanted global variables, why would I need
Framework anyway? What's the added value there?
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
What if we included the subclass in the box? Both the old and the new are designed to work smoothly with subclasses. I'm not sure I understand why we would need two classes - why is it better than having once class? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bill Karwin wrote: I've updated the proposal page started by Gavin and Andries with yet another proposed solution, Solution E. I populated the class skeletons to illustrate this solution. I would prefer Solution E (of course :-). Looks good to me and appears to have general acceptance too! Regards, Rob... -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF7y7B421+qn4cITwRAoQVAJ4zZJYoeBCD3wqvRRPSPAIj57gLAwCfWuUB sN4Zgbrs+SkSa0I6ZnAgeiQ= =GKSw -END PGP SIGNATURE-
Re: [fw-general] Zend.php proposal
I really don't think [the proposed Zend_Log::debug() method]
is a good replacement for Zend::dump.
I agree. However, I think having a method for dumping objects to a log is
good to have in tandem with the existing, simple dump() function. Both
would preferably be made available through a Zend_Debug class.
OK, make it get() and put() - but it should be *easy*. It should not
require knowing about singletons and instances. The concept of putting
and getting variable in registry is simple, so should be acting on this
concept in framework. If you want to do complex stuff (like having
multiple registries) then it can be complex, but easy actions should be
done by easy code. That's why we have SimpleXML - that's why we should
have SimpleRegistry and SimpleDump :)
In any event, whenever you're dealing with the registry, it's rarely just
getting a single value out of it. It's getting multiple values (Cache,
Db, View, etc.).
Compare:
$registry = Zend_Registry::getInstance();
$cache= $registry-cache;
$db = $registry-db;
$view = $registry-view;
vs.
$cache = Zend_Registry::get('cache');
$db= Zend_Registry::get('db');
$view = Zend_Registry::get('view');
The first example seems easier to me.
Anyway, you only need to instantiate the object once in each controller's
init() method.
public function init()
{
$this-_registry = Zend_Registry::getInstance();
// Or $this-_registry = $this-getInvokeArg('registry');
}
Errr? So we went all this long way with registry - only to get back to
global variables? If I wanted global variables, why would I need
Framework anyway? What's the added value there?
No one's suggesting using a global variable, only that it is possible to
use Zend_Registry in many different ways. I prefer to pass it as an
invocation argument to the front controller, which makes it available to
all actions. Most others probably prefer the Singleton interface.
You mentioned that new users will find the Singleton pattern confusing.
If someone isn't familiar with basic design patterns, they'll probably
find the internals of most of the components in the framework confusing or
mysterious. For example, the front controller (it uses a Singleton as
well). But just because users might not understand the internals doesn't
mean they can't use it. That's what the manual is for.
-Matt
Re: [fw-general] Zend.php proposal
I didn't find any reasons given for changing the existing registry API
in Zend.php to the one in the proposal.
Does anyone else want or need a static setter/getter for Zend_Registry?
Static methods can not have the same names as public methods. The
$this variable is not set when invoking a static method on an instance
object. Combining Zend.php's static registry methods into Zend_Registry
requires the static getter/setter methods to remain inconsistent with
the names of the getter and setter methods for instance objects (as it
is now in Zend.php and Zend_Registry.php). However, nothing prevents us
from changing the names to something less confusing :)
For option C/E in the proposal, moving static setters/getters to a
subclass of Zend_Registry minimizes bloat in Zend_Registry.php.
However, this argument is weak, since the total bloat is very small.
What is simpler?
Current way in Zend.php / Zend_Registry.php:
$registry = Zend::registry();
$registry['key1'] = 'value1';
$registry['key2'] = 'value2';
Zend::register('key1') = 'value1';
Zend::register('key2') = 'value2';
New way in proposal:
$registry = Zend_Registry::getInstance();
$registry['key1'] = 'value1';
$registry['key2'] = 'value2';
Alternative new way:
Zend_Registry::set($key, $value);
Zedn_Registry::get($key);
With the above get(), the current instance method version of get() in
the proposal is replaced with a method that only works on the global
registry stored in the static class variable. Instance methods for
accessors remain the same as for ArrayObject (i.e. inherited as they are
now in Registry.php).
Cheers,
Gavin
Stanislav Malyshev wrote:
What if we included the subclass in the box?
Both the old and the new are designed to work smoothly with subclasses.
I'm not sure I understand why we would need two classes - why is it
better than having once class?
Re: [fw-general] Zend.php proposal
Anyway, you only need to instantiate the object once in each controller's
init() method.
public function init()
{
$this-_registry = Zend_Registry::getInstance();
// Or $this-_registry = $this-getInvokeArg('registry');
}
Here you make assumption that I use MVC and implement init() methods for
controllers. But many of the uesers would do neither, and using MVC
should not be related to using registry. Registry should be easy to use
with or without MVC. Using getInstance() requires you to know that
Registry is a singleton which is working in certain way. It is the
knowledge that in most cases you do not need.
No one's suggesting using a global variable, only that it is possible to
Well, I distinctly remember an email where somebody *was* suggesting
using global variable ;)
use Zend_Registry in many different ways. I prefer to pass it as an
invocation argument to the front controller, which makes it available to
all actions. Most others probably prefer the Singleton interface.
Again, you assume everybody uses MVC with front controller and everybody
knows what Singleton is and prefers to use it. I don't see how any of
these things should be prerequisite for using the registry.
You mentioned that new users will find the Singleton pattern confusing.
No, I don't think they should get even to finding Singleton pattern
*anything*. They don't need to know about it's existence. They shouldn't
be bothered by it.
If someone isn't familiar with basic design patterns, they'll probably
find the internals of most of the components in the framework confusing or
mysterious. For example, the front controller (it uses a Singleton as
The we already lost the game and should return to the design stage,
because deep knowledge of design patterns as the prerequisite for using
any framework is totally unacceptable if we talking about PHP target
audience. It can help you do advanced stuff, but it should not be
required. Basic usage should be - *extremely simple*.
Fortunately, I disagree with that assumption - most interfaces in
framework do not require knowledge of design patterns, unless these very
interfaces are done with purpose of implementing those patterns (like
MVC) and unless you want to do advanced stuff that requires in-depth
understanding of how Framework components are implemented. You don't
need any patterns to use Zend_Feed or Zend_Db - you just instantiate the
class and use it. We should keep it that way.
well). But just because users might not understand the internals doesn't
mean they can't use it. That's what the manual is for.
In the case of over-designed interfaces - they have to. Framework should
be so easy to use that you don't really need to read the manual for at
least basic usage - just to look at a couple of the examples and be
intuitively ready to use it without even diving into the details. Of
course, it is not always possible - if you talk about complex stuff. But
trivial stuff should stay trivial.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Current way in Zend.php / Zend_Registry.php:
$registry = Zend::registry();
$registry = Zend_Registry::getInstance();
I like first one more, since it doesn't bother me with unneeded
knowledge about instances.
Alternative new way:
Zend_Registry::set($key, $value);
Zedn_Registry::get($key);
Same here. Of course, if we had class getters/setters it would be even
cooler, but unfortunately you can't do Zend_Registry::$key = $value yet
:) AFAIK. I'd still prefer put() to set(), but this is not that important.
With the above get(), the current instance method version of get() in
the proposal is replaced with a method that only works on the global
registry stored in the static class variable. Instance methods for
accessors remain the same as for ArrayObject (i.e. inherited as they are
now in Registry.php).
We can keep the getInstance() if you wish for those who love patterns
and singletons, but this should not be the only way. What I mean is:
static public function put($key, $value) {
$me = self::getInstance();
$me[$key] = $value;
}
etc.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
RE: [fw-general] Zend.php proposal
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
We can keep the getInstance() if you wish for those who love patterns
and singletons,
So it is the name getInstance() that is so off-putting?
My first wording for the design named the method
Zend_Registry::default(), but I thought that wasn't clear enough. I
thought getInstance() would be clearer.
but this should not be the only way. What I mean is:
static public function put($key, $value) {
$me = self::getInstance();
$me[$key] = $value;
}
That sounds fine to me. As long as it's not called register() and
registry()!
I have updated the proposal page. But it has to work statically and
dynamically, so I made $me set either to $this or self::getInstance().
Regards,
Bill Karwin
Re: [fw-general] Zend.php proposal
So it is the name getInstance() that is so off-putting? Well, that and having to use it each time I need the registry. Actually, the latter - if I have get/put, I could live with getInstance for advanced stuff. That sounds fine to me. As long as it's not called register() and registry()! OK with me. I think get/put is better than register/registry anyway :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
The result looks good, although calling instance methods statically
seems more like a bug than a feature to me ;)
All issues raised are addressed, except Zend::registry() vs.
Zend_Registry::getInstance().
What if Zend_Registry::getRegistry() was an alias of
Zend_Registry::getInstance()?
Then the user doesn't need to know or understand the connotations of
getInstance().
Cheers,
Gavin
Bill Karwin wrote:
-Original Message-
From: Stanislav Malyshev [mailto:[EMAIL PROTECTED]
We can keep the getInstance() if you wish for those who love patterns
and singletons,
So it is the name getInstance() that is so off-putting?
My first wording for the design named the method
Zend_Registry::default(), but I thought that wasn't clear enough. I
thought getInstance() would be clearer.
but this should not be the only way. What I mean is:
static public function put($key, $value) {
$me = self::getInstance();
$me[$key] = $value;
}
That sounds fine to me. As long as it's not called register() and
registry()!
I have updated the proposal page. But it has to work statically and
dynamically, so I made $me set either to $this or self::getInstance().
Regards,
Bill Karwin
RE: [fw-general] Zend.php proposal
but this should not be the only way. What I mean is:
static public function put($key, $value) {
$me = self::getInstance();
$me[$key] = $value;
}
That sounds fine to me. As long as it's not called register() and
registry()!
I have updated the proposal page. But it has to work statically and
dynamically, so I made $me set either to $this or self::getInstance().
if (isset($this)) {
$instance = $this;
} else {
$instance = self::getInstance();
}
Which would be great, but it doesn't work.
class Registry
{
function get()
{
if (isset($this)) {
print '$this is defined (' . get_class($this) . ')br /';
} else {
print '$this is not definedbr /';
}
}
}
class IndexController
{
function indexAction()
{
Registry::get();
$registry = new Registry();
$registry-get();
}
}
$index = new IndexController();
$index-indexAction();
// Outputs:
$this is defined (IndexController)
$this is defined (Registry)
You could check the class name in Registry, but either way it's going to
give you an E_STRICT error. Methods cannot be called in both static and
object contexts in PHP if they refer to $this at any time.
-Matt
Re: [fw-general] Zend.php proposal
Which would be great, but it doesn't work. Actually I don't see why you need non-static get if you already have array and object syntax working. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
All issues raised are addressed, except Zend::registry() vs. Zend_Registry::getInstance(). What if Zend_Registry::getRegistry() was an alias of Zend_Registry::getInstance()? Then the user doesn't need to know or understand the connotations of getInstance(). Perhaps we can also provide aliases for Zend_Controller_Front::getInstance() (getController()) and Zend_Auth::getInstance() (getAuth()). That's sarcasm, but I'm not trying to be rude. :-) It just feels like there's a line between ease of use and treating users like children, and it's crossed at the point when it obfuscates the API for knowledgeable users--in this case, those that would immediately understand what getInstance() refers to, but might see examples using getRegistry() and be confused as to the difference. Instead of dumbing down the API, why not encourage users to learn about these concepts? If one of the goals of the project is raising the overall level of the PHP community (which isn't explicitly stated, but which I feel is implied), hiding these concepts from novice users is not the way to go about it. Perhaps the manual can have a short section on design patterns, with overviews of those found in the framework. Each component could then link to the ones they use, to help facilitate this educational process. -Matt
RE: [fw-general] Zend.php proposal
What if Zend_Registry::getRegistry() was an alias of
Zend_Registry::getInstance()?
I'm not in favor of this; aliases that offer no difference in
functionality or usability are not consistent with the goal of
protecting users from excessive choices.
But now that we think of the get() method as static-only, as Stas points
out there is no need to call it on an object, then get() with no
arguments is actually equivalent to getInstance(). The getInstance()
method doesn't need to be public at all.
So the usage to get the default static registry is:
$r = Zend_Registry::get();
These three are equivalent:
Zend_Registry::get('foo')
$r-offsetGet('foo');
$r['foo'];
These three are equivalent:
Zend_Registry::set('foo', 'bar')
$r-offsetSet('foo', 'bar)
$r['foo'] = 'bar';
The old Zend::initRegistry('classname') method is a bit more clearly
named:
Zend_Registry::setClassName('classname')
This is needed only by people who want to use a subclass as the static
registry instance.
From: Matthew Ratzloff [mailto:[EMAIL PROTECTED]
Perhaps the manual can have a short section on design patterns, with
overviews of those found in the framework. Each component could then
link
to the ones they use, to help facilitate this educational process.
I think educating users on design patterns is a fine idea. It would be
great to see a series of articles on DevZone about implementing design
patterns in PHP. In fact, it's such a good idea that there already is
such a series of articles on DevZone. :-)
http://devzone.zend.com/search/results?q=pattern
But it's probably not something that needs to be in the Zend Framework
manual. Stas is right that the principle of extreme simplicity in ZF
should make it unnecessary to know design patterns just to use ZF.
Education is always beneficial, but one doesn't need to be a mechanic to
drive a car.
Regards,
Bill Karwin
Re: [fw-general] Zend.php proposal
OK with me. Only point is we need to ensure we don't get strange result
with call to get($foo) when $foo is not defined or defined to some
strange value. But actually if you give me get/set I can tolerate
getInstance too. :)
I'm not in favor of this; aliases that offer no difference in
functionality or usability are not consistent with the goal of
protecting users from excessive choices.
But now that we think of the get() method as static-only, as Stas points
out there is no need to call it on an object, then get() with no
arguments is actually equivalent to getInstance(). The getInstance()
method doesn't need to be public at all.
So the usage to get the default static registry is:
$r = Zend_Registry::get();
These three are equivalent:
Zend_Registry::get('foo')
$r-offsetGet('foo');
$r['foo'];
These three are equivalent:
Zend_Registry::set('foo', 'bar')
$r-offsetSet('foo', 'bar)
$r['foo'] = 'bar';
The old Zend::initRegistry('classname') method is a bit more clearly
named:
Zend_Registry::setClassName('classname')
This is needed only by people who want to use a subclass as the static
registry instance.
--
Stanislav Malyshev, Zend Products Engineer
[EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
I don't mind it being Zend_Debug::dump(), but I don't want people to believe that the Debug class will contain methods to set breakpoints, monitor variables, perform traces, generate code profiling reports, or No, I in no way want this stuff. It doesn't belong to framework realm. I just want to have the ad-hoc methods intact :) Like dump, maybe some better backtrace later, but nothing more. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/
Re: [fw-general] Zend.php proposal
Matthew, Heh, I expected some feedback on this. Point taken and accepted :) There has been some inconsistency in the ZF for balance points between simplicity and complexity of component APIs. Often, comparing two extreme alternatives helps rule out alternatives, hopefully leaving a plausible alternative in the middle. Personally, I think the sum total of everything a junior PHP developer can learn in about one or two hours of reading introductory material from the ZF manual ought to be at least available as candidate material for use in the portion of ZF API's aimed at serving the 80+% type use cases. Whatever the final name is for registry()/getInstance(), it will be in the ZF demo tutorial. However, I think using get() with no arguments isn't consistent with the expectations of those who are familiar with getInstance(), as used elsewhere in the ZF. Thus, I'm not in favor of changing getInstance() to get() and creating an exception. Cheers, Gavin Matthew Ratzloff wrote: All issues raised are addressed, except Zend::registry() vs. Zend_Registry::getInstance(). What if Zend_Registry::getRegistry() was an alias of Zend_Registry::getInstance()? Then the user doesn't need to know or understand the connotations of getInstance(). Perhaps we can also provide aliases for Zend_Controller_Front::getInstance() (getController()) and Zend_Auth::getInstance() (getAuth()). That's sarcasm, but I'm not trying to be rude. :-) It just feels like there's a line between ease of use and treating users like children, and it's crossed at the point when it obfuscates the API for knowledgeable users--in this case, those that would immediately understand what getInstance() refers to, but might see examples using getRegistry() and be confused as to the difference. Instead of dumbing down the API, why not encourage users to learn about these concepts? If one of the goals of the project is raising the overall level of the PHP community (which isn't explicitly stated, but which I feel is implied), hiding these concepts from novice users is not the way to go about it. Perhaps the manual can have a short section on design patterns, with overviews of those found in the framework. Each component could then link to the ones they use, to help facilitate this educational process. -Matt
Re: [fw-general] Zend.php proposal
Just trying to catch up on the goings on... boy you lot are busy people! Anyway, from a skim read +1 again for E. On 8 Mar 2007, at 01:32, Gavin Vess wrote: Whatever the final name is for registry()/getInstance(), it will be in the ZF demo tutorial. However, I think using get() with no arguments isn't consistent with the expectations of those who are familiar with getInstance(), as used elsewhere in the ZF. Thus, I'm not in favor of changing getInstance() to get() and creating an exception. Cheers, Gavin ditto. getInstance() appears in quite a few places, and changing just this one to get() doesn't feel right. I also am finding it hard to understand what is so bad about the word 'instance'. If anything I think it's useful that it says instance, as it tells me the additional information that this is a single occurrence of whatever it is I'm getting. Cheers Nick
