Re: New function proposal: spl_class_vars / params / contents

Christian Schneider wrote:

Lukas Kahwe Smith wrote:

On 21.01.2009, at 12:00, Karsten Dambekalns wrote:

On 21.01.2009 11:44 Uhr, Kenan R Sulayman wrote:

I did propose the function because the construction in user-land is quite expensive;

Reflection is expensive, indeed. The way we solved it for FLOW3 is to create a ReflectionService that caches such information as long as the source doesn't change.

yeah its a general problem .. but so far the decision has been that we should move away from adding more and more functions/methods for highly specialized cases (as in not continue in the get_class() etc. approach). now speeding up reflections is a very real issue .. suggestions in this regard are quite welcome. maybe offering a cache service as part of core is one approach ..

Yes, please. Keep clutter out of the engine especially for stuff which should not be used often. If you are relying on Reflection to be fast for you everyday code then you're IMHO doing something weird and it is ok that you have to write your own caching for it (-:C

seems to me that many of the new requests coming in, including my own stupid ones are because people want to build fast decent orm's in php - a definitive list of what one needs to make an orm in php, the userland approaches possible, what could be implemented in php and what couldn't might be good. address the whole thing in a oner. quite sure the requests and need is only going to grow.. imho it's being encouraged by the increasing numbers using PDO - it kind of suggests building an orm :p also, very unlike me, but a service to cache reflection classes is quick and simple to implement in userland - (although if there is a free speed up to reflection going I'll 'ave some)