Electronics & Programming

develissimo

Open Source electronics development and programming

  • You are not logged in.
  • Root
  • » PHP
  • » [PHP-DEV] RFC __autodefine / spl_autodefine [RSS Feed]

#1 Dec. 6, 2010 19:42:23

Pierre J.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] RFC __autodefine / spl_autodefine


hi,

Please put it in the wiki :)

On Mon, Dec 6, 2010 at 8:38 PM, Loon, Reinier van
<reinier.van.l***@*mail.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             function name
> a\b\foo, System::boot, SomeClass->getWidth
>  T_CLASS                   class name
>   Image, ns\Image
>  T_INTERFACE           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

Offline

#2 Dec. 6, 2010 20:02:58

Sebastian B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] RFC __autodefine / spl_autodefine


On 12/06/2010 08:38 PM, Loon, Reinier van wrote:Note: Whenever __autodefine is used, also spl_autodefine is meant.__autoload() should die (as in get deprecated ASAP and later removed),
please do not add new __auto*() functions. Note that this does not mean
that I agree or disagree with the functionality itself.

--
Sebastian Bergmann Co-Founder and Principal Consultanthttp://sebastian-bergmann.de/http://thePHP.cc/--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#3 Dec. 7, 2010 01:00:25

Ross M.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] RFC __autodefine / spl_autodefine


Hi Sebastien,


> __autoload() should die (as in get deprecated ASAP and later removed)


I couldn't find anything about your opinions on this so I was wondering if
you could elaborate. Do you consider autoloading as a bad practice or just
that spl_autoload_register should be used to add relevant
functions/closures?

Regards, Ross

On 6 December 2010 20:01, Sebastian Bergmann <sebast***@*hp.net> wrote:

> On 12/06/2010 08:38 PM, Loon, Reinier van wrote:
>
>> Note: Whenever __autodefine is used, also spl_autodefine is meant.
>>
>
> __autoload() should die (as in get deprecated ASAP and later removed),
> please do not add new __auto*() functions. Note that this does not mean
> that I agree or disagree with the functionality itself.
>
> --
> Sebastian Bergmann Co-Founder and Principal Consultant
>http://sebastian-bergmann.de/http://thePHP.cc/>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit:http://www.php.net/unsub.php>
> --
Ross Masters <r...@php.net>http://rossmasters.com/

Offline

#4 Dec. 7, 2010 04:44:20

Larry G.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] RFC __autodefine / spl_autodefine


On Monday, December 06, 2010 6:59:08 pm Ross Masters wrote:
> Hi Sebastien,
>
> > __autoload() should die (as in get deprecated ASAP and later removed)
>
> I couldn't find anything about your opinions on this so I was wondering if
> you could elaborate. Do you consider autoloading as a bad practice or just
> that spl_autoload_register should be used to add relevant
> functions/closures?

__autoload() works fine if you have exactly one implementation for your entire
system with exactly one set of logic for how to map a class name to a file
name. As soon as you try to mix two different libraries together, fatal
error.

spl_autoload() does not suffer from this short-sighted problem but
accomplishes the same goal in a much more robust fashion.

Any new meta-auto-load mechanism should forego the dead-end that is a single
unique __auto*() function and just use a design that actually works, aka
spl_autoload() or similar.

With that said, I like the idea of generalizing autoload to include functions
et al. Autoloading functions would make my life a lot easier. :-) To be
fair, though, half of the potential benefits the OP listed are already solved
by using a version control system. Any version control system. If you're
still having collisions at the file level when two people work on the same
file it's because you're an idiot and are not using version control (or the
changes touch each other, in which case this proposal wouldn't help you
anyway).

The main advantage of this proposal would be lazy-loading of functions. I
don't think autoloading methods makes any sense since classes cannot be split
between files anyway.

I'm not entirely sure what else is actually reasonable to autoload. Classes,
Interfaces, Functions, and Traits make up the scope of first-class code
structures, don't they? Autoloading a variable doesn't even make sense to me,
and include files are already handled by include.

--Larry Garfield

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

#5 Dec. 7, 2010 07:28:58

Sebastian B.
Registered: 2009-11-02
Reputation: +  0  -
Profile   Send e-mail  

[PHP-DEV] RFC __autodefine / spl_autodefine


Am 07.12.2010 05:44, schrieb Larry Garfield:
> spl_autoload() does not suffer from this short-sighted problem but
> accomplishes the same goal in a much more robust fashion.

Exactly.

--
Sebastian Bergmann Co-Founder and Principal Consultanthttp://sebastian-bergmann.de/http://thePHP.cc/--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:http://www.php.net/unsub.php

Offline

  • Root
  • » PHP
  • » [PHP-DEV] RFC __autodefine / spl_autodefine [RSS Feed]

Board footer

Moderator control

Enjoy the 21st of October
PoweredBy

The Forums are managed by develissimo stuff members, if you find any issues or misplaced content please help us to fix it. Thank you! Tell us via Contact Options
Leave a Message
Welcome to Develissimo Live Support