Ultragreen Software

autoload¶

En regardant micon (post précédant), je suis tomber sur un verbe Ruby que je ne connaissais pas!
On peut faire du Ruby depuis 10 ans et être passé à côté de ça ? et bien oui !
autoload qui d'ailleur est un faux ami,
Vous voyez le AUTOLOAD (démoniaque) de Perl, et bien "ça na rien à voir!"(c) zj, ic, prae(s) et ... ça me rajeunit pas tout ça...
il ne s'execute pas comme un pre-hook au require d'un fichier, mais il fait autre chose, "c'est comme Gif-sur-Yvette, c'est différent..." (c) les mêmes, (spéciale dédicace pour Ic, je suis nostalgique moi en ce moment....)

Explication¶

En fait le autoload Ruby, c'est bien ! surtout quand on code modulaire et que potentiellement certains modules ne sont pas exploités ou rarement mais qu'on veut pas se faire _ pendant l'initialisation de l'application, je m'explique par l'exemple :

Exemple :¶

$ vi mon_module_optionel.rb
--

 1 
 2 module MonModule
 3 
 4   def MonModule::init
 5     puts 'initialisation'
 6     # init code
 7   end
 8 
 9   # methods ...
10   def self.test
11     #nop
12   end
13 
14 end
15 
16 MonModule::init
17 

test via irb¶

Avec require¶

irb(main):001:0> require 'mon_module_optionel'
initialisation
=> true

Avec autoload¶

irb(main):001:0> autoload :MonModule, 'mon_module_optionel'
=> nil
irb(main):002:0> include MonModule
initialisation
=> Object

Observation¶

On voit bien que le load réel (interpretation) est différé, mais le compilateur n'hurle pas de NameError, car il "s'attend" a trouver un namespace (module,classe) avec comme nom la Constante fournit à autoload.
en gros on enregistre le symbole du namespace :MonModule est on y l'associe à un wrapper qui va faire le require qui va charger le code, détachant le wrapper au profis du module ou de la classe voulue. c'est beau !

Dans l'exemple j'ai fait un include, mais MonModule.test aurait fournit le même résultat, jouer avec un classe aussi en faisant un new.