Class Autoloading

To explore this idea (from my previous post), I've pushed the
classrename scenario, which renames the classes in the DD module, more
or less along the lines of the PEAR naming scheme (name reflects the
folder hierarchy the class is in).

I'm no big fan of long underscored class names, but I think the tradeoff
is worth it in this case. Over a hundred sys::imports were removed,
along with a cluster of files which were basically doing nothing but
making sure some classes were imported.

Granted some of this may have been past sloppiness, but the point is
that using the autoload mechanism automatically ensures that only what's
actually needed is loaded. Like the consistent use of interfaces, saves
us from ourselves.

Extending this to other modules is straightforward, since by convention
the modules all have their classes in the "class" folder. In the case of
the core it's less clear where the disadvantages begin to outweigh the
benefits, as the class structure of the core is not as homogeneous and
simple as that of the modules.
_______________________________________________
Xaraya_devel mailing list
Xaraya_devel@...
http://xaraya.com/mailman/listinfo/xaraya_devel

[Marcel van der Boom-2]

On 23 jul 2009, at 19:46, marcinmilan@... wrote:

> ... but the point is
> that using the autoload mechanism automatically ensures that only  
> what's
> actually needed is loaded. Like the consistent use of interfaces,  
> saves
> us from ourselves...

One thing to keep in mind perhaps is performance. The rationale for  
the import method back then was speed, nothing more, nothing less.  
There should be some notes of my benchmarking on mailing lists or in  
repository. At the time autoload was so buggy it was not even worth  
considering, this may have improved (it should).

The penalty for autoloading (apart from some ad-hoc naming convention)  
is that the system has /some/ information on where to look for certain  
classes, to be used at the time a class is not found as opposed to  
the /exact/ information sys::import provides.
I have no idea what the search time penalty for that is, but it may be  
worth benchmarking that, at least for the common inclusion routes.

I remember being somewhat surprised by the 'include_once vs include'  
penalty back then, as in that it was much higher than i had thought.

marcel


--
Marcel van der Boom  -- http://hsdev.com/mvdb.vcf
HS-Development BV    -- http://www.hsdev.com
So! web applications -- http://make-it-so.info
Cobra build          -- http://cobra.mrblog.nl




_______________________________________________
Xaraya_devel mailing list
Xaraya_devel@...
http://xaraya.com/mailman/listinfo/xaraya_devel

Marcel van der Boom wrote:

> On 23 jul 2009, at 19:46, marcinmilan@... wrote:
>
>> ... but the point is
>> that using the autoload mechanism automatically ensures that only what's
>> actually needed is loaded. Like the consistent use of interfaces, saves
>> us from ourselves...
>
> One thing to keep in mind perhaps is performance. The rationale for the
> import method back then was speed, nothing more, nothing less. There
> should be some notes of my benchmarking on mailing lists or in
> repository. At the time autoload was so buggy it was not even worth
> considering, this may have improved (it should).
>
> The penalty for autoloading (apart from some ad-hoc naming convention)
> is that the system has /some/ information on where to look for certain
> classes, to be used at the time a class is not found as opposed to the
> /exact/ information sys::import provides.
> I have no idea what the search time penalty for that is, but it may be
> worth benchmarking that, at least for the common inclusion routes.

In this scenario the autoload function has the exact information and can
go load the correct file directly. For the performance reason you
mention I don't see this exercise as going beyond cases where the exact
information is known, which for now are the classes in the modules'
class directories and (maybe) the core classes under lib/xaraya. I don't
think it even makes sense to use the mechanism for loading dataproperty
classes, or for that matter the interface classes we use in some places.

In the two cases above, however, the performance hit should be: failing
to find the class among those loaded, and then calling the autoload
function, which itself is already loaded. One would expect that to be
quite small.

Cherry picking the cases in which to use the mechanism introduces a bit
of confusion perhaps ("when do I need to use sys::import?"), but on the
other hand most classes live in the background, and the occasional
module developer will probably not often have to worry about this issue.

For module developers, I think the mechanism could be useful because it
gives some guidance on where to place their classes and how to name
them, apart from the obvious advantage of allowing them to skip the
sys::import lines in the code.

Marc
_______________________________________________
Xaraya_devel mailing list
Xaraya_devel@...
http://xaraya.com/mailman/listinfo/xaraya_devel