Autoboxing in PHP

Am 04.05.2010 05:48, schrieb Moriyoshi Koizumi:

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .

Regards,
Moriyoshi

Hi,
I think you should mention that this extension basically would prohibit
adding methods on primitive types later, which is probably more
efficient and allows one to use the same methods on the primitive types
in every php app you write.
I fear that a lot of people will (have) to come up with their own string
libraries, int libraries etc. which will have (subtle) differences.
Guess you code for two projects, one using the autbox library X and one
library Y. Would you always remember which methods you're allowed to
call on an int, or the order of parameters, especially when there are
many methods which have a similar name?
Imho, the way to go here is implementing eg the array_* family of
functions directly in php as methods for arrays, etc.
Cornelius

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .

Regards,
Moriyoshi

Is there any reason why primitives couldn't be autoboxed to SplInt,
SplBool, etc.? These classes could maybe even be extended with method
aliases to the relevant functions in PHP's library.

--
Daniel Egeberg

Hi,

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .

It looks like a very interesting idea. However, I believe that we
should learn from the __autoload experience: It does not cope well
with multiple projects. I'd rather have register_autoboxer($callback)
or even register_autoboxer("type", $callback); for instance, so that
many projects could have their own autoboxer.

Best,

Regards,
Moriyoshi

--

--
Etienne Kneuss
http://www.colder.ch

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .

I liken this to pecl/runkit. "For all those things you.... probably
shouldn't have been doing anyway". It will create a world where scripts
are not portable. And if you need that for your internal project, that
is fine. But, having this as part of the PHP core would be a disaster.
This is even more heinous than __autoload(), IMO. SPL fixed this for
autoload. I would support an SPL extenstion to treat primitive types as
SPL objects. They are standardized. Not random.

Brian.

brianlmoon@php.net
http://brian.moonspot.net/

Hi Moriyoshi,

I took just a quick look through the patch, but for me it looks like a
bad idea. Introducing new magic function may bring a lot of troubles and
open a new door for exploit writer (we already have problems with
__toString() method). Also I afraid, this magic method will make php
slower even if scripts don't use this future (at least the patch
disables code specialization for ZEND_INIT_METHOD_CALL) and make some
future type propagation optimizations non-applicable. At last the patch
introduces 18 new grammar conflicts and I think it's not acceptable.

Thanks. Dmitry.

Moriyoshi Koizumi wrote:

Hey,

Just to let you know about a new RFC for adding autoboxing feature in PHP.
Look at http://wiki.php.net/rfc/autoboxing .

Regards,
Moriyoshi