[Solar-talk] Namespacing with concrete class functionality

[Rodrigo Moraes]

On 11/8/06, Travis Swicegood wrote:
> One thing I haven't tried yet is replacing all of the Solar specific
> loadClass() class with loadClass("Solar_Some_Class", true) so they're
> all concrete.  Assuming I'm correct, the $concrete parameter should add
> fractions of a percent to the execution time.  That would be the ideal
> situation, in my opinion.  Make Solar the flex point, and as you build
> your application, you make it concrete as speed becomes necessary.

I don't understand how would you change the $concrete parameter when
you need. Changing Solar classes would be too bad for maintenance and
upgrades. I hope this is not the idea, is it? In this case I prefer to
define a "classes" config array: all the loadClass() are supposed to
be concrete, except when you define that one or another are not. I
still like the idea of defining "replacements" manually in case
performance is affected too much.

> Another thing that's come to mind would be a memcache'd array for
> loadClass() that stores known locations of requested classes.  This is
> would be nice regardless of namespaces or not.  Of course, not everyone
> has access to memcache, so it would have to be made optional.
> Refactoring loadClass() so it's the interface into a Solar_Class_Locator
> object would allow you to configure what type of locator you use.

I would like a lot a Solar_Class_Locator. :-) This would allow people
to try new approaches more easily. Those looking for performance could
have a locator that even doesn't rely on include path - the path could
be configured directly. Also a locator could be used to trim classes
and cache them in various ways, for those looking for extreme
performance.

> Drop
> in a Solar_Class_Locator_Memcache and it could cache an array of known
> classes and their locations - that removes the entire finding process
> which is the expensive part of this equation.

I have a bad experience with this: you'll still need to clean the
array sometimes. For me it would be easier to define it when I need it
to change. It would force some discipline and avoid when you think you
are loading one class but you are in fact loading another one. :-|
Defining replacements manually would have the benefit to try to force
people to use Solar classes ;-) as much as possible, which is a good
thing imo.

In any case, I think a Solar_Class_Locator would be a great thing.

rodrigo

---------------------------------------------------------------------
Solar has now a Community Wiki: solarphp.org
---------------------------------------------------------------------
Join the #solarphp IRC channel on freenode.org
---------------------------------------------------------------------