Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:50878
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.161.42 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:in-reply-to:references:date:message-id:subject:from:to
         :cc:content-type:content-transfer-encoding;
        b=ng717hjTDf7IuhK7pDgJS2P4WyQvodJ/uCzH+KVMW4g6uyI7GDS4hzFYUdhUVirefm
         4hj5exNaTdDOS8HgxtnoJDq7tGWFQ0ShKR7VFX2qsru+3nwUvV3/GMv6AXYesigHd4hm
         9KKC5596a7tNoAY28UtiDM1dhxiKXA4LwotMU=
MIME-Version: 1.0
In-Reply-To: <AANLkTin2X62fd=-5Wksww_qy8y+beXTxJTkrDvWzqXoq@mail.gmail.com>
References: <AANLkTin2X62fd=-5Wksww_qy8y+beXTxJTkrDvWzqXoq@mail.gmail.com>
Date: Mon, 6 Dec 2010 20:40:51 +0100
Message-ID: <AANLkTimWV25yOe8euyUGagL1JYUU+Bv=5GL9CDd74wPG@mail.gmail.com>
To: "Loon, Reinier van" <reinier.van.loon@gmail.com>
Cc: internals@lists.php.net
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] RFC __autodefine / spl_autodefine
From: pierre.php@gmail.com (Pierre Joye)

hi,

Please put it in the wiki :)

On Mon, Dec 6, 2010 at 8:38 PM, Loon, Reinier van
<reinier.van.loon@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 functio=
n.
> 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
>
> =A0__autodefine( $name, $type )
>
> =A0$name is the string of the missing definition
>
> =A0$type is the integer identification of the type and defined by constan=
ts.
>
>
> =A0$type constant =A0 =A0 =A0 =A0 =A0 =A0$name format
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0name examples
>
> =A0T_FUNCTION =A0 =A0 =A0 =A0 =A0 =A0 [namespace][class name][::|->]funct=
ion name
> a\b\foo, System::boot, SomeClass->getWidth
> =A0T_CLASS =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 [namespace]class name
> =A0 Image, ns\Image
> =A0T_INTERFACE =A0 =A0 =A0 =A0 =A0 [namespace]class name =A0 =A0 =A0 =A0 =
=A0 Image, ns\Image
> =A0T_INCLUDE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0file name
> =A0somefile, ../somefile, \includes\Somefile
> =A0T_INCLUDE_ONCE =A0file name
> somefile, ../somefile, \includes\Somefile
> =A0T_REQUIRE =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0file name
> =A0somefile, ../somefile, \includes\Somefile
> =A0T_REQUIRE_ONCE =A0file name
> somefile, ../somefile, \includes\Somefile
>
>
> Code examples
>
> =A0foo(b); =A0 =A0 =A0 =A0 =A0 =A0// __autodefine( 'foo', T_FUNCTION )
>
> =A0p =3D new PHP(); =A0 =A0 // __autodefine( 'PHP', T_CLASS )
>
> =A0include 'piece' =A0 =A0// __autodefine( 'piece', T_INCLUDE )
>
> =A0ons\foo(); =A0 =A0 =A0 =A0 // __autodefine( 'ons\foo', T_FUNCTION )
>
> =A0p->im(); =A0 =A0 =A0 =A0 =A0 // __autodefine( 'PHP->im', T_FUNCTION )
>
> =A0p->cm(); =A0 =A0 =A0 =A0 =A0 // __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 =A0a 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 (=3D 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
>
>



--=20
Pierre

@pierrejoye | http://blog.thepimp.net | http://www.libgd.org