RFC Autoboxing Draft View as Markdown

2013/2/25 Nils Andre nilsandre@gmail.com

Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.

== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.

== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.

Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.

== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)

By adding autoboxing for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.

== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).

== Syntax ==
The mapping is very straigtforward. Consider this:

$a = "This is a string";

$b = $a->toUpperCase() --> $b = ucase($a)
$b = $a->substring(0,4) --> $b = substr($a, 0, 4)

It would also allow many brilliant constructs like the following

if ($b->startsWith("This")) { ... }

in contrast to

if (substr($b,0,4) == "This") { ... }

Must say, that for now I didn't read your mail completely, but this example
is .. it doesn't fit. The problem is, that you compare two different
semantics.

function startsWith($string, $startsWith) {
return !strncmp($string, $startsWith, strlen($startsWith));
}

$b->startsWith('This');
startsWith($b, 'This');

Now they aren't that different anymore.

Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.

No: strlen($string)

== Compatibility ==
The old notation could be switched on/off at any time.

The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some "use
\PHP5*;" or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
"old"/compatibility stuff.

== Advantages ==

• Cleanup of the language
• Consistency and predictability improved a lot (also in constrast to
  possible userland classes - which would then all be slightly different)
• No lacking backwards compatibility
• Easier learning for new PHP programmers (beginners to PHP would be much
  more pointed to learning OOP than procedural programming)
• Easier switching for programmers from Java to using PHP and vice versa
  (now that PHP grew very mature, attract the Java folks with the cool stuff
  PHP offers)
• Little overhead (as far as I am aware) to implement
• Nicer language syntax (see References)

== Disadvantages ==

• I don't know how complicated it is to implement. So far we don't have any
  extensions for this on PECL, except for strong typing (see reference). From
  a theoretical point of view, it is just mapping.
• There might be heaps of ways to implement, as the other autoboxing RFC
  offers one possiblity. Certainly we need discussion on the best way to
  implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
  suggests to map primitive types to some objectual syntax.

== References ==
This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle
of
nicer syntax.

[[

http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/
]]
implements a sort of userland "autoboxing" in PHP.

[[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation
of PECL SPL_Types, which make strongly-typed classes for primitive types
available. While they implement strong typing (if wanted), they do not
offer syntax cleanup.

--
github.com/KingCrunch

It's a good idea, IMHO. This particular paragraph should probably be removed:

"It would also allow many brilliant constructs like the following

if ($b->startsWith("This")) { ... }

in contrast to

if (substr($b,0,4) == "This") { ... }

Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left."

The problem with this paragraph is that you are comparing apples to
oranges. If PHP wanted a starts_with function, it could add one
without autoboxing. Stick to benefits that are achieved specifically
by autoboxing.

It's also possible to achieve consistency without autoboxing. You
could introduce:

str_substr
str_begins_with
str_find

Et cetera, et cetera, and always put the haystack first, and you would
have consistency.

However the OOP syntax forces you to be consistent, at least about the
"first argument" (which, with autoboxing, becomes the object you are
invoking a "method" upon). And this is a good thing because it reduces
the risk of inconsistencies creeping in.

Also, the OOP syntax that you're using for the other half of your code
and with which developers are already comfortable from other
languages.

I think it's important to make these points in the RFC, and avoid
issues that can be addressed equally well without autoboxing such as
your substr() example.

Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.

== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.

== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.

Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.

== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)

By adding autoboxing for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.

== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).

== Syntax ==
The mapping is very straigtforward. Consider this:

$a = "This is a string";

$b = $a->toUpperCase() --> $b = ucase($a)
$b = $a->substring(0,4) --> $b = substr($a, 0, 4)

It would also allow many brilliant constructs like the following

if ($b->startsWith("This")) { ... }

in contrast to

if (substr($b,0,4) == "This") { ... }

Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.

== Compatibility ==
The old notation could be switched on/off at any time.

The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some "use
\PHP5*;" or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
"old"/compatibility stuff.

== Advantages ==

• Cleanup of the language
• Consistency and predictability improved a lot (also in constrast to
  possible userland classes - which would then all be slightly different)
• No lacking backwards compatibility
• Easier learning for new PHP programmers (beginners to PHP would be much
  more pointed to learning OOP than procedural programming)
• Easier switching for programmers from Java to using PHP and vice versa
  (now that PHP grew very mature, attract the Java folks with the cool stuff
  PHP offers)
• Little overhead (as far as I am aware) to implement
• Nicer language syntax (see References)

== Disadvantages ==

• I don't know how complicated it is to implement. So far we don't have any
  extensions for this on PECL, except for strong typing (see reference). From
  a theoretical point of view, it is just mapping.
• There might be heaps of ways to implement, as the other autoboxing RFC
  offers one possiblity. Certainly we need discussion on the best way to
  implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
  suggests to map primitive types to some objectual syntax.

== References ==
This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of
nicer syntax.

[[
http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/]]
implements a sort of userland "autoboxing" in PHP.

[[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation
of PECL SPL_Types, which make strongly-typed classes for primitive types
available. While they implement strong typing (if wanted), they do not
offer syntax cleanup.

--
Tom Boutell
P'unk Avenue
215 755 1330
punkave.com
window.punkave.com

Hello,

See the reply inline:

Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.

Follow the steps described here in order to get RFC karma and everything
should be fine: https://wiki.php.net/rfc/howto :)

== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.

== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.

I'm not very comfortable with the autoboxing of --everything--. Could you please
detail why autoboxing anything that's not array or string would be
useful? I like
the idea of autoboxing for strings / arrays, where the most problems related
to parameters order would be solved but for the other types, as a developer
I can't see it.

Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.

== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)

By adding autoboxing for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.

== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).

== Syntax ==
The mapping is very straigtforward. Consider this:

$a = "This is a string";

$b = $a->toUpperCase() --> $b = ucase($a)
$b = $a->substring(0,4) --> $b = substr($a, 0, 4)

It would also allow many brilliant constructs like the following

if ($b->startsWith("This")) { ... }

in contrast to

if (substr($b,0,4) == "This") { ... }

Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.

This should be done in a transparent manner imho. The current substr
function should be mapped to String::substr() as well.

I'd recommend you play a bit with this: https://github.com/nikic/scalar_objects
and come up with some examples on how the classes would look like
before going forward with this proposal.

== Compatibility ==
The old notation could be switched on/off at any time.

The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some "use
\PHP5*;" or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
"old"/compatibility stuff.

IIRC disabling functionality via ini settings isn't a desired thing.
As for namespaces
I think it's a bad idea. Currently everything in PHP is global, not
namespace and
this introduces a new layer for programmers to learn of.

== Advantages ==

• Cleanup of the language
• Consistency and predictability improved a lot (also in constrast to
  possible userland classes - which would then all be slightly different)
• No lacking backwards compatibility
• Easier learning for new PHP programmers (beginners to PHP would be much
  more pointed to learning OOP than procedural programming)
• Easier switching for programmers from Java to using PHP and vice versa
  (now that PHP grew very mature, attract the Java folks with the cool stuff
  PHP offers)
• Little overhead (as far as I am aware) to implement
• Nicer language syntax (see References)

== Disadvantages ==

• I don't know how complicated it is to implement. So far we don't have any
  extensions for this on PECL, except for strong typing (see reference). From
  a theoretical point of view, it is just mapping.
• There might be heaps of ways to implement, as the other autoboxing RFC
  offers one possiblity. Certainly we need discussion on the best way to
  implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
  suggests to map primitive types to some objectual syntax.

== References ==
This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of
nicer syntax.

[[
http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/]]
implements a sort of userland "autoboxing" in PHP.

[[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation
of PECL SPL_Types, which make strongly-typed classes for primitive types
available. While they implement strong typing (if wanted), they do not
offer syntax cleanup.

Currently I'm playing around with a demo implementation of this feature but
it's private at the moment, still in early stages. I'd be happy to work on and
provide a patch for this later on. Currently all the RFCs should be targeted
for PHP-next (5.6) so there's no rush for this imho.

Have a nice day

Florin Patan
https://github.com/dlsniper

strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:

Hi,
"not going too much into details here"

First, [lease do go into details, this is exactly what it is about.
I can'tpeven begin to fathom what you think autoboxing has to do with
variable order on string functions.

Second, that article might be a lot of things, but "summary" is surely
the worst way to describe it. "Semi-complete, semi-outdated rant
covering every current and past flaw in PHP" might be a better one.

And lastly, if you're suggesting a "startsWith" method on a proposed
String Object, that still has nothing to do with an Autoboxing RFC -
it's step 2 or 3 after the language would have Autoboxing.

Greetings,
Florian

There is also a PECL extension already under development that will
probably fill this void so many people would like to see filled.

Hi Everyone on the list, I have no RFC Karma here so far, so I post this to
the list at first. There has been ongoing discussion about new APIs and so
fort, so this is a suggestion for language cleanup by Autoboxing. I'd
really appreciate comments.

== Introduction ==
This RFC tries to approach the need for Autoboxing in PHP, or, to make
primitive types behave as if they were objects when being used or accessed
in an objectional fashion. Autoboxing can be discussed from various
perspectives, which is far beyond the scope of this document, which much
more addresses the fact that the language of PHP must be cleaned up in
order to grow more in terms of maturity and hence, in user accpetance.

== Autoboxing in brief ==
Autoboxing is that we can use primitive types, like integers, strings,
booleans and array as if they were objects, but without being constructed
as objects themselves.

Autoboxing is widely discussed, and somehow a must-have in OOP as a
consequence to having primitive types (for the sake of performance and
memory overhead) but keeping the language OOP-consistent.

== Why PHP needs it ==
PHP needs autoboxing as a means to restructure the language and make it
more predictable. One big flaw of today's PHP is, that it is unstructured
and chaotic with its builtin functions, as, for example, those dealing with
strings. Not going too much into details here, many programmes always have
to look up the function definition because very similar functions have
their parameters in different orders or simply don't act in a predictive,
well-structured manner. This article is a good read to sum it up:

http://me.veekun.com/blog/2012/04/09/php-a-fractal-of-bad-design/

The problem derives from the fact that PHP has not been designed top-down,
but has been developed the bottom-up way over many years: As of today, the
language offers features other languages don't have, but struggles with
it's buried bodies from the past (mainly because compatibility had and
still has to be kept.)

By adding autoboxing for all primitive types (Booleans, Strings,
Integers, Arrays), we would clean up the language in a very consistent
manner, but still retain backwards compatibility.

== How it could be implemented ==
We would not need much programming, because we simply map the new autoboxed
notation to the old code. We suggest the new notation to reproduce the Java
notation and parameter sequence closely, because it is pretty
straightforward and consistent (see, for example, the Javadocs on
java.lang.String).

== Syntax ==
The mapping is very straigtforward. Consider this:

$a = "This is a string";

$b = $a->toUpperCase() --> $b = ucase($a)
$b = $a->substring(0,4) --> $b = substr($a, 0, 4)

It would also allow many brilliant constructs like the following

if ($b->startsWith("This")) { ... }

in contrast to

if (substr($b,0,4) == "This") { ... }

Notice that the latter is error-prone, because if the condition changes one
would always have to match the string on the right handside to the length
of it on the left.

== Compatibility ==
The old notation could be switched on/off at any time.

The old notation would be switched on by default until, say, PHP 6, and can
then be enabled/disabled by either a compile flag, INI setting or some "use
\PHP5*;" or something on top of a PHP file, which then makes the old
notation available to any code that follows/any file that is included
afterwards. As a consequence, \PHP5 will be the namespace comprising all
"old"/compatibility stuff.

== Advantages ==

• Cleanup of the language
• Consistency and predictability improved a lot (also in constrast to
  possible userland classes - which would then all be slightly different)
• No lacking backwards compatibility
• Easier learning for new PHP programmers (beginners to PHP would be much
  more pointed to learning OOP than procedural programming)
• Easier switching for programmers from Java to using PHP and vice versa
  (now that PHP grew very mature, attract the Java folks with the cool stuff
  PHP offers)
• Little overhead (as far as I am aware) to implement
• Nicer language syntax (see References)

== Disadvantages ==

• I don't know how complicated it is to implement. So far we don't have any
  extensions for this on PECL, except for strong typing (see reference). From
  a theoretical point of view, it is just mapping.
• There might be heaps of ways to implement, as the other autoboxing RFC
  offers one possiblity. Certainly we need discussion on the best way to
  implement. Maybe also "autoboxing" is the wrong word, as this RFC simply
  suggests to map primitive types to some objectual syntax.

== References ==
This RFC [[https://wiki.php.net/rfc/autoboxing]] views it from the angle of
nicer syntax.

[[
http://php.webtutor.pl/en/2011/04/13/strong-data-typing-in-php-part-ii-autoboxing-and-indestructable-objects-english-version/]]
implements a sort of userland "autoboxing" in PHP.

[[http://www.php.net/manual/en/intro.spl-types.php]] is the documentation
of PECL SPL_Types, which make strongly-typed classes for primitive types
available. While they implement strong typing (if wanted), they do not
offer syntax cleanup.

--
-Clint