hi, Please put it in the wiki :)
On Mon, Dec 6, 2010 at 8:38 PM, Loon, Reinier van <reinier.van.l...@gmail.com> wrote: > RFC __autodefine / spl_autodefine > > This proposal proposes to introduce one function for automagically > defining missing definitions at run time. > The reader should have a reasonable level of PHP knowledge and > computer languages when reading this proposal. > Note: Whenever __autodefine is used, also spl_autodefine is meant. > > Current situation > > PHP currently supports defining missing classes by the __autoload function. > This solution mimics the class loader concept from Java. > Once defined, undefined class functions (methods) can be emulated by > using __call and __callStatic. > It can be argued that __autoload is enough for the future if the > future is object-oriented. > > > Proposition > > While very useful in its own right __autoload is limited: only classes > can be loaded dynamically. > However, there is still a lot of code that is either mixed functional > and object-oriented or only functional. > Excluding that code from such a solution makes life very hard on > everyone maintaining mixed code bases. > It is understandable that by denying this function to non-object > oriented code an incentive exists for maintainers and developers to > switch to object-oriented programming. > Although understandable it is not acceptable, for the following reasons: > 1) There are enough people maintaining and writing code in a perfect > manner that do not grasp object orientation > 2) Any large code base should have the possibility to slowly migrate > and not be coerced into an object oriented way of working > 3) Even if this coercion would work, it would not guarantee the > solution is object-oriented, only that it is coded in classes > > So, it can be stated that a number of language constructs are missing > the option to autoload. > > From a conceptual point, tokens in a sequence of statements refer to > definitions. The implementation of almost all run time environments > demands that a definition exists before first referenced. __autoload > changed this rule by allowing classes to be defined when the execution > of a statement hits on an undefined class. This behaviour should be > generalized. > > Generally, it can be said that PHP needs a mechanism for automagically > defining undefined elements. The proposed name for that function is > __autodefine. The parameters to this function would be $name and > $type. The type parameter would refer to all the existing elements > that are defined. Probably the maximal set of language constructs that > could be supported are: T_ARRAY, T_CLASS, T_CLASS_C, T_CONST, > T_FUNCTION T_FUNC_C, T_INCLUDE, T_INCLUDE_ONCE, T_INTERFACE, > T_METHOD_C, T_NAMESPACE, T_NS_C, T_REQUIRE, T_REQUIRE_ONCE, T_USE, > T_VAR, T_VARIABLE. The author believes the minimal solution should > support at least T_FUNCTION, T_CLASS, T_INTERFACE and include > (T_INCLUDE, T_INCLUDE_ONCE, T_REQUIRE, T_REQUIRE_ONCE). Namespaces > will be part of the name as is the case in call_user_func. > > The relation with the current implementation is that __autoload equals > __autodefine( $name, T_CLASS ) with the exception of the optional > file_extensions parameter. __autoload need not be changed and > __autodefine can live alongside __autoload. Author believes __autoload > should be marked 'deprecated'. > > > Minimal solution proposal > > __autodefine( $name, $type ) > > $name is the string of the missing definition > > $type is the integer identification of the type and defined by constants. > > > $type constant $name format > name examples > > T_FUNCTION [namespace][class name][::|->]function name > a\b\foo, System::boot, SomeClass->getWidth > T_CLASS [namespace]class name > Image, ns\Image > T_INTERFACE [namespace]class name Image, ns\Image > T_INCLUDE file name > somefile, ../somefile, \includes\Somefile > T_INCLUDE_ONCE file name > somefile, ../somefile, \includes\Somefile > T_REQUIRE file name > somefile, ../somefile, \includes\Somefile > T_REQUIRE_ONCE file name > somefile, ../somefile, \includes\Somefile > > > Code examples > > foo(b); // __autodefine( 'foo', T_FUNCTION ) > > p = new PHP(); // __autodefine( 'PHP', T_CLASS ) > > include 'piece' // __autodefine( 'piece', T_INCLUDE ) > > ons\foo(); // __autodefine( 'ons\foo', T_FUNCTION ) > > p->im(); // __autodefine( 'PHP->im', T_FUNCTION ) > > p->cm(); // __autodefine( 'PHP::cm', T_FUNCTION ) > > > Advantages > > A whole new array of possibilities opens up for managing code, both at > run time and both at design time (development). Code is no longer > bound to file containers. Small pieces of code can exist on their own. > At run time only the code pieces that are needed for execution are > defined. No longer parsing of complete files when only 5 code lines > will be executed. A parse error in a file not relevant to the piece of > code that will be executed will not prevent execution anymore. By > splitting code up, developers can work side by side on the same code > base, every developer on a set of code pieces, much smaller than the > files now and thus reducing (locking) conflicts. Code pieces can be > tested standalone and accepted. Progress is measurable on function > level. Requirements can be tied to their functions. Basically, a lot > of metafunctions are suddenly possible because splitting up code in > smaller pieces has become a workable solution. Code could be for > example managed like in a wiki, with page (= code piece) revisions > etc. If needed the code pieces can be assembled into any number of > files for delivery. An extreme solution is assembling all the code > pieces into a zip file and having a run time implementation of > __autodefine that picks definitions from a zip file. While the same > code is available during development in a wiki. Large codebases can be > split up over time into more manageable pieces giving the developers > renewed control over their application. The __autodefine function will > enable all sorts of new ways of managing code and work processes. > Security can be enhanced enormously as it is not common anymore where > definitions will come from and how they are decrypted. Even if someone > gets access to the source code (outside the web root), it might be > scrambled. Also insight into the system can be obtained by observing > definition patterns that can be gathered during the autodefine > processing. > > > Disadvantages > > Initially execution may be slower. However, this can be countered with > different implementations for __autodefine at production time and > development time. The author also believes that others will find ways > to counter this disadvantage by using caching or keeping definitions > in memory inbetween executions. > > > Conclusion > > The minimal solution to support all definitions would be the function > __autodefine( $name, $type ). From there on, every developer can > determine his/her own strategy for automagically defining > implementations. The __autodefine function enables developers to split > code up into smaller pieces as before while at the same time make it > manageable by removing the need to include all these functions. By > splitting code up in smaller pieces more developers can work together > on one (1) code base. A parse error in a function that is not called > will not damage the run time as is the case in the current > implementation where many functions are grouped into files for reasons > of manageability. __autodefine also enables developers to utilize all > sorts of autodefinition mechanisms like retrieving definitions from > the file system, the network, a zip file or even a database. Even > multiple sources can be used, runtime versioning mechanisms can be > utilized, code decryption on the fly is possible. It would be even > interesting if the autodefinition could be in the form of byte codes. > > The __autodefine function is generic enough that the same concept can > be applied in most other languages. > > The request is to supply at least the minimal __autodefine in a very > near future version of PHP. To be complete and consistent spl_ > autodefine_ call, spl_ autodefine_ extensions, spl_ autodefine_ > functions, spl_ autodefine_ register, spl_ autodefine_ unregister and > spl_ autodefine should be defined (although considered not necessary > according to the author). > > Reinier van Loon > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
