Re: [PHP-DEV] The future of objects and operators

2022-06-14 Thread Robert Landers
On Fri, May 13, 2022 at 4:49 PM Jordan LeDoux  wrote:
>
> On Fri, May 13, 2022 at 7:05 AM Rowan Tommins 
> wrote:
>
> >
> > I like Larry's "4 levels", but I've been thinking that there's some
> > existing functionality in PHP which takes a different direction: rather
> > than overloading *operators*, the language lets you overload *behaviour*.
> > We have magic methods like __get and __call, and interfaces like Iterator,
> > Countable, and ArrayAccess. Some hook into a particular function, or even
> > operator, but they're generally described in terms of what they do, not
> > what they look like, if you see what I mean.
> >
> > From that point of view, overloading comparison and equality *behaviour*
> > makes sense - it could affect not just the == and <=> operators, but things
> > like in_array() and sort(). I think this distinction is more pronounced in
> > PHP than some languages, because the standard library isn't "self-hosted":
> > a sort() call doesn't literally compile to a call to $a <=> $b
> >
> >
> I have been thinking about something similar, but not in the context of
> making operator overloads more like behavior overloads. Rather, I've been
> considering the idea that operator overloads are a *subset* of *engine
> overloads*. Ways that the developer can provide additional details to the
> engine about the behavior of their code that allows the engine to make more
> concrete assumptions about how it should be processed and interpreted.
>
> I started thinking about this mainly from the perspective of the syntax. I
> proposed the `operator +()` syntax in my overloads RFC, but my most
> compelling argument about the reason for it was sort of obscured because it
> was wrapped up in only overloads. To that end, I was considering more
> broadly what *all* magic methods are on objects: handlers. In fact, in the
> Zend engine that's how many of the same sorts of behaviors are described,
> as object handlers.
>
> Most of the standard library functions don't make calls for such handlers.
> For instance, sort() makes a call to zend_compare, and zend_compare ends up
> making a call to the compare handler on the relevant object. So I was at
> least considering the idea of a more broad replacement of the syntax for
> object behaviors, just not for an RFC related to overloads... such an RFC
> would have its own difficulties and controversy, and would almost certainly
> require a period of dual syntax support for old magic method syntax, making
> the arguments against very easy while the benefits would be more long term
> and less immediately apparent.
>
>
> > It's less obvious how that applies to mathematical operators - should
> > implementing "addition" allow an object to be used with array_sum()
> > perhaps? And what about deriving one operation from another, e.g. $foo*3
> > running $foo+$foo+$foo, or $foo**3 running $foo*$foo*$foo?
> >
> > I don't really have a conclusion here, I just wanted to throw it out there
> > as a different mental model to consider.
> >
> >
> This would only be true for numerics, but not other kinds of math, such as
> matrices. Mathematical operators really are something that require direct
> calls and direct overloads if they are supported in any way, unless the
> language is willing to essentially never have things like complex numbers,
> matrices, etc. even in extensions.
>
> Still, it's an interesting thought and definitely the kind of high-level
> discussion I was looking for.
>
> Jordan

Sorry to resurrect an old conversation, but today I'm doing some
complex/big-number math (with a compatibility layer around GMP) in
PHP, and it made me realize how much I'd appreciate at least some
operator support in PHP.

Current code:

function modNear(BN $a, BN $b): BN {
$res = $a->mod($b);
if($res->gt($b->shrn(1))) {
return $res->sub($b);
}
return $res;
}

Desired code:

function modNear(BN $a, BN $b): BN {
$res = $a % $b;
if($res > ($b >> 1)) {
return $res - $b;
}
return $res;
}

The latter is much easier to grok at a glance.

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



Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Jordan LeDoux
On Fri, May 13, 2022 at 7:05 AM Rowan Tommins 
wrote:

>
> I like Larry's "4 levels", but I've been thinking that there's some
> existing functionality in PHP which takes a different direction: rather
> than overloading *operators*, the language lets you overload *behaviour*.
> We have magic methods like __get and __call, and interfaces like Iterator,
> Countable, and ArrayAccess. Some hook into a particular function, or even
> operator, but they're generally described in terms of what they do, not
> what they look like, if you see what I mean.
>
> From that point of view, overloading comparison and equality *behaviour*
> makes sense - it could affect not just the == and <=> operators, but things
> like in_array() and sort(). I think this distinction is more pronounced in
> PHP than some languages, because the standard library isn't "self-hosted":
> a sort() call doesn't literally compile to a call to $a <=> $b
>
>
I have been thinking about something similar, but not in the context of
making operator overloads more like behavior overloads. Rather, I've been
considering the idea that operator overloads are a *subset* of *engine
overloads*. Ways that the developer can provide additional details to the
engine about the behavior of their code that allows the engine to make more
concrete assumptions about how it should be processed and interpreted.

I started thinking about this mainly from the perspective of the syntax. I
proposed the `operator +()` syntax in my overloads RFC, but my most
compelling argument about the reason for it was sort of obscured because it
was wrapped up in only overloads. To that end, I was considering more
broadly what *all* magic methods are on objects: handlers. In fact, in the
Zend engine that's how many of the same sorts of behaviors are described,
as object handlers.

Most of the standard library functions don't make calls for such handlers.
For instance, sort() makes a call to zend_compare, and zend_compare ends up
making a call to the compare handler on the relevant object. So I was at
least considering the idea of a more broad replacement of the syntax for
object behaviors, just not for an RFC related to overloads... such an RFC
would have its own difficulties and controversy, and would almost certainly
require a period of dual syntax support for old magic method syntax, making
the arguments against very easy while the benefits would be more long term
and less immediately apparent.


> It's less obvious how that applies to mathematical operators - should
> implementing "addition" allow an object to be used with array_sum()
> perhaps? And what about deriving one operation from another, e.g. $foo*3
> running $foo+$foo+$foo, or $foo**3 running $foo*$foo*$foo?
>
> I don't really have a conclusion here, I just wanted to throw it out there
> as a different mental model to consider.
>
>
This would only be true for numerics, but not other kinds of math, such as
matrices. Mathematical operators really are something that require direct
calls and direct overloads if they are supported in any way, unless the
language is willing to essentially never have things like complex numbers,
matrices, etc. even in extensions.

Still, it's an interesting thought and definitely the kind of high-level
discussion I was looking for.

Jordan


Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Larry Garfield
On Fri, May 13, 2022, at 9:05 AM, Rowan Tommins wrote:
> On 6 May 2022 23:16:37 BST, Jordan LeDoux  wrote:
>>I'm not sure at this point how voters think objects and operators should
>>work together into the future. I'd like to see if anyone is willing to have
>>high-level discussion about the ideas, instead of picking at the
>>implementation or details of a particular RFC.
>
>
> Hi Jordan,
>
> I like Larry's "4 levels", but I've been thinking that there's some 
> existing functionality in PHP which takes a different direction: rather 
> than overloading *operators*, the language lets you overload 
> *behaviour*. We have magic methods like __get and __call, and 
> interfaces like Iterator, Countable, and ArrayAccess. Some hook into a 
> particular function, or even operator, but they're generally described 
> in terms of what they do, not what they look like, if you see what I 
> mean.
>
> From that point of view, overloading comparison and equality 
> *behaviour* makes sense - it could affect not just the == and <=> 
> operators, but things like in_array() and sort(). I think this 
> distinction is more pronounced in PHP than some languages, because the 
> standard library isn't "self-hosted": a sort() call doesn't literally 
> compile to a call to $a <=> $b
>
> It's less obvious how that applies to mathematical operators - should 
> implementing "addition" allow an object to be used with array_sum() 
> perhaps? And what about deriving one operation from another, e.g. 
> $foo*3 running $foo+$foo+$foo, or $foo**3 running $foo*$foo*$foo?
>
> I don't really have a conclusion here, I just wanted to throw it out 
> there as a different mental model to consider.

Interesting point.  I think that's the most compelling argument I've heard for 
using `public function __lessThan` rather than `operator <`.  I'm not sure if 
it's enough to change my own preference on that front, but it's an interesting 
point.  Working with `in_array()` and `sort()` is a necessary feature for 
comparison overloading, IMO.  I'm unsure about something like `array_sum()`, 
but could be convinced.

Hum.

--Larry Garfield

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



Re: [PHP-DEV] The future of objects and operators

2022-05-13 Thread Rowan Tommins
On 6 May 2022 23:16:37 BST, Jordan LeDoux  wrote:
>I'm not sure at this point how voters think objects and operators should
>work together into the future. I'd like to see if anyone is willing to have
>high-level discussion about the ideas, instead of picking at the
>implementation or details of a particular RFC.


Hi Jordan,

I like Larry's "4 levels", but I've been thinking that there's some existing 
functionality in PHP which takes a different direction: rather than overloading 
*operators*, the language lets you overload *behaviour*. We have magic methods 
like __get and __call, and interfaces like Iterator, Countable, and 
ArrayAccess. Some hook into a particular function, or even operator, but 
they're generally described in terms of what they do, not what they look like, 
if you see what I mean.

From that point of view, overloading comparison and equality *behaviour* makes 
sense - it could affect not just the == and <=> operators, but things like 
in_array() and sort(). I think this distinction is more pronounced in PHP than 
some languages, because the standard library isn't "self-hosted": a sort() call 
doesn't literally compile to a call to $a <=> $b

It's less obvious how that applies to mathematical operators - should 
implementing "addition" allow an object to be used with array_sum() perhaps? 
And what about deriving one operation from another, e.g. $foo*3 running 
$foo+$foo+$foo, or $foo**3 running $foo*$foo*$foo?

I don't really have a conclusion here, I just wanted to throw it out there as a 
different mental model to consider.

Regards,

-- 
Rowan Tommins
[IMSoP]

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



Re: [PHP-DEV] The future of objects and operators

2022-05-12 Thread Jordan LeDoux
On Mon, May 9, 2022 at 2:25 PM Larry Garfield 
wrote:

>
> Also, not proposing level 1 on the grounds that it would reduce the
> argument for level 2/3 in the future would effectively be holding level 1
> functionality "hostage" for the more advanced versions, which... would
> probably not work out well. :-)  (Even if that's not your intent, it would
> come off that way.)
>
>
>
Yes, I also realize that, which is another reason I'm thinking that doing
comparison-only overloads first might be the better way forward.


Re: [PHP-DEV] The future of objects and operators

2022-05-09 Thread Larry Garfield
On Sat, May 7, 2022, at 3:59 PM, Jordan LeDoux wrote:

> Of the people who did vote no and also provided me feedback, there were
> *mainly* three reasons given (some in public such as on this list, and some
> in private in more direct conversation):
>
> 1. Math is not a valid use case.
> 2. Operator overloading for objects is something I will vote against in any
> context for any design, no matter the argument or evidence provided.
> 3. Operator overloading presents problems for static analysis and tooling
> which are more significant than the benefits.
>
> I could argue against all three positions, but as you noted, I don't think
> argument or debate is really helpful right now. Instead I'd like to talk at
> a more high level about what sort of long-term future PHP contributors and
> voters see for objects when it comes to allowing developers to control
> object behavior.
>
> I like the way you organized the different levels of support within the
> feature, it's a good organizational structure for thinking about the
> feature-set. Given the feedback though, I found myself a little concerned
> that if I created a Level 1 proposal, it's very possible that the people in
> groups 1 and 3 above might vote for it. However, in doing so it's also very
> possible that all the use-cases those voters care about would then be
> covered, and many would then block anything which helps use-cases they do
> not commonly use. In essence, the particular feedback I received made me
> concerned that passing a Level 1 RFC would basically guarantee that Level
> 2+ would never happen until the voter base itself was significantly changed.

It's possible.  However, it wouldn't be the first feature that has laid dormant 
for several years until the voting population turned over.  (Scalar types and 
attributes are the first such examples that come to mind, but I'm sure there's 
others.)

Also, not proposing level 1 on the grounds that it would reduce the argument 
for level 2/3 in the future would effectively be holding level 1 functionality 
"hostage" for the more advanced versions, which... would probably not work out 
well. :-)  (Even if that's not your intent, it would come off that way.)

Conversely, giving people a version or three to work with level 1 operator 
overloads may get more people comfortable with the concept and thus make them 
more amenable to levels 2 or 3 in the future.

Whether there's enough support for level 1 for it to pass at the moment, I 
honestly don't know.  

> Even so... I think I agree with your suggestion at this point. At the very
> least, even if my concern above was proven true, it would then at least be
> *possible* for me to provide an extension for PHP which addresses some of
> the shortcomings for math.
>
> The main issue when it comes to comparisons is addressed in the PR I
> linked, which basically boils down to "for objects, it makes sense for
> equatable and comparable to be separated sometimes". Whether this involves
> a fall-through in the VM for objects as done in my linked PR, or involves
> new handlers for objects as CMB commented on that PR instead, it's actually
> a very minor change technically within the engine to implement Level 1
> support as you described it.
>
> Jordan

I defer to you and others on the technical implementation, as it's well outside 
my wheelhouse.

--Larry Garfield

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



Re: [PHP-DEV] The future of objects and operators

2022-05-08 Thread Andreas Leathley

On 07.05.22 22:59, Jordan LeDoux wrote:

I like the way you organized the different levels of support within the
feature, it's a good organizational structure for thinking about the
feature-set. Given the feedback though, I found myself a little concerned
that if I created a Level 1 proposal, it's very possible that the people in
groups 1 and 3 above might vote for it. However, in doing so it's also very
possible that all the use-cases those voters care about would then be
covered, and many would then block anything which helps use-cases they do
not commonly use. In essence, the particular feedback I received made me
concerned that passing a Level 1 RFC would basically guarantee that Level
2+ would never happen until the voter base itself was significantly changed.

Creating "smaller steps" (within a certain feature set) seems to have
been the more successful route for PHP RFCs and not necessarily slowed
down further enhancements, in my estimation. The more one single RFC is
about, the more there is to possibly dislike. It is also easier to
reason about less changes at any one point in time and make a more
compelling case for the changes. So I think your overall goal of more
feature-complete operator overloading remains viable even if you start
"small" with a level 1 proposal.

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



Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread MKS Archive


> On May 6, 2022, at 6:16 PM, Jordan LeDoux  wrote:
> 
> Hello all,
> 
> I took a while away after my operator overload RFC was declined. I've been
> mulling for the last few months how to move forward while respecting the
> concerns and feedback of those who abstained and those who voted against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.
> 
> # There is Considerable Demand For Improved Control of Operators with
> Objects
> 
> This doesn't apply to all operators. I have not seen any comments in the
> last few months of digging of people who are desperate for the pow operator
> ( ** ) for instance. However, many people who work with math in PHP have
> use for at least the arithmetic operators and I see this comment frequently.
> 
> Totally separate from the math domain, I've seen many comments about the
> desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This
> is something that would have numerous applications outside of mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by Rudi
> to implement just comparisons.
> 
> # Different Voters Have Different Concerns
> 
> This is an issue that almost all RFC authors must deal with of course, but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than mine,
> there were comments that a full operator overloading solution should be
> provided instead of something halfway.
> 
> However one of the comments I received more than once was that I should
> separate out the comparison operators into its own RFC, since those have
> applications outside the math domain.
> 
> # Is Math A Valid Use Case?
> 
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use case in
> PHP. I am... unsure about what to think of this opinion. I guess I would
> like to discuss and find out if this is widely believed among voters.

I will repeat what I suggested back before the RFC was voted on, and that is 
you consider *starting* your campaign for operator overloads with an RFC to add 
a built-in Math class (or set of classes) to PHP, one(s) that can have all the 
operator overloading it/they need(s).

Minimally the design process in the open would be insightful for everyone 
interested in the topic even if the RFC did not get accepted — although the 
intent should be that it would — because it would change the operator overload 
discussion from a very abstract one to a very concrete one. 

It could also illustrate the benefit for operator overloading, and illustrate 
the design process of deciding on how operators are overloaded and what the 
benefits and tradeoffs are of different choices.

If the RFC did not pass, at least it could result in an understanding of which 
operators minimally need to be overloaded for the Math use-case and serve as a 
blueprint for adding Math objects in userland if and when sufficient 
general-purpose operator overloading could get added to PHP.

Further, if an RFC to add a built-in Math object to PHP passed it would 
effectively eliminate the red-herring of "I don't do heavy math work."  Such an 
RFC would also, of course, not have the other two (2) categories of objections 
that you named in your other email.

Again, #jmtcw

-Mike

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



Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread Jordan LeDoux
On Sat, May 7, 2022 at 11:40 AM Larry Garfield 
wrote:

>
> I would group object operators into 4 categories/levels.
>
> 1. Object-universal operators.  This would be support for operators that
> make sense in all domains.  Mainly this is the comparison operators but
> there may be others.
> 2. Arithmetic operators.  The 4 basic operations.  Maybe even just 3
> (excluding division as it's a bit more complex than the others
> conceptually).
> 3. Full operator overloading: If an operator exists, a class can override
> it, on principle, even if there's no obvious common use case.
> 4. Custom overloading: User-space can define additional operators for
> specific objects.
>
> Jordan's RFC was effectively level 3, with a syntax designed to be
> extensible to level 4 in the future if desired.  Naturally the line between
> these levels if a little bit fuzzy and there's some overlap.
>   ...

I frankly think this is a red herring; it's a "I don't do heavy math work
> in PHP, so arguing that feature X makes PHP better for math carries no
> weight."  It shouldn't be read as "PHP being good at complex computations
> is bad in itself."  (If anyone does actually believe that, I'd say speak up
> but I'd just tell you that you're wrong from the get-go, so maybe let's not
> pick that fight and leave it as a hypothetical. :-) )
> ...
> My recommendation would be to use the same syntax and model as before and
> just target object-universal operators, ie, comparisons.  (Level 1 from
> above.)  That gets the syntax in place, and lets us flush out the engine
> hook weirdness.  If we could get that to pass, it would at least get people
> comfortable with the idea and concept.  The higher level parts could then
> be an easier sell in the future in a version or two once people have gotten
> more used to the idea.
>
>
Of the people who did vote no and also provided me feedback, there were
*mainly* three reasons given (some in public such as on this list, and some
in private in more direct conversation):

1. Math is not a valid use case.
2. Operator overloading for objects is something I will vote against in any
context for any design, no matter the argument or evidence provided.
3. Operator overloading presents problems for static analysis and tooling
which are more significant than the benefits.

I could argue against all three positions, but as you noted, I don't think
argument or debate is really helpful right now. Instead I'd like to talk at
a more high level about what sort of long-term future PHP contributors and
voters see for objects when it comes to allowing developers to control
object behavior.

I like the way you organized the different levels of support within the
feature, it's a good organizational structure for thinking about the
feature-set. Given the feedback though, I found myself a little concerned
that if I created a Level 1 proposal, it's very possible that the people in
groups 1 and 3 above might vote for it. However, in doing so it's also very
possible that all the use-cases those voters care about would then be
covered, and many would then block anything which helps use-cases they do
not commonly use. In essence, the particular feedback I received made me
concerned that passing a Level 1 RFC would basically guarantee that Level
2+ would never happen until the voter base itself was significantly changed.

Even so... I think I agree with your suggestion at this point. At the very
least, even if my concern above was proven true, it would then at least be
*possible* for me to provide an extension for PHP which addresses some of
the shortcomings for math.

The main issue when it comes to comparisons is addressed in the PR I
linked, which basically boils down to "for objects, it makes sense for
equatable and comparable to be separated sometimes". Whether this involves
a fall-through in the VM for objects as done in my linked PR, or involves
new handlers for objects as CMB commented on that PR instead, it's actually
a very minor change technically within the engine to implement Level 1
support as you described it.

Jordan


Re: [PHP-DEV] The future of objects and operators

2022-05-07 Thread Larry Garfield
On Fri, May 6, 2022, at 5:16 PM, Jordan LeDoux wrote:
> Hello all,
>
> I took a while away after my operator overload RFC was declined. I've been
> mulling for the last few months how to move forward while respecting the
> concerns and feedback of those who abstained and those who voted against.
> But I feel like a separate discussion needs to happen first after
> considering many different approaches.

Speaking only for myself, of course...

> # There is Considerable Demand For Improved Control of Operators with
> Objects
>
> This doesn't apply to all operators. I have not seen any comments in the
> last few months of digging of people who are desperate for the pow operator
> ( ** ) for instance. However, many people who work with math in PHP have
> use for at least the arithmetic operators and I see this comment frequently.
>
> Totally separate from the math domain, I've seen many comments about the
> desire to control the comparison operators: >, >=, ==, <=, <, !=, <>. This
> is something that would have numerous applications outside of mathematics,
> and there's even been an RFC worked on (that was declined in 2018) by Rudi
> to implement just comparisons.

I would group object operators into 4 categories/levels.

1. Object-universal operators.  This would be support for operators that make 
sense in all domains.  Mainly this is the comparison operators but there may be 
others.
2. Arithmetic operators.  The 4 basic operations.  Maybe even just 3 (excluding 
division as it's a bit more complex than the others conceptually).
3. Full operator overloading: If an operator exists, a class can override it, 
on principle, even if there's no obvious common use case.
4. Custom overloading: User-space can define additional operators for specific 
objects.

Jordan's RFC was effectively level 3, with a syntax designed to be extensible 
to level 4 in the future if desired.  Naturally the line between these levels 
if a little bit fuzzy and there's some overlap.

> # Different Voters Have Different Concerns
>
> This is an issue that almost all RFC authors must deal with of course, but
> this particular subject suffers from it more severely than most. For
> instance, in some of the past proposals that were more limited than mine,
> there were comments that a full operator overloading solution should be
> provided instead of something halfway.
>
> However one of the comments I received more than once was that I should
> separate out the comparison operators into its own RFC, since those have
> applications outside the math domain.

See above regarding "levels" of support.

> # Is Math A Valid Use Case?
>
> One of the more shocking (to me personally) pieces of feedback that I
> received from more than one person is that math is not a valid use case in
> PHP. I am... unsure about what to think of this opinion. I guess I would
> like to discuss and find out if this is widely believed among voters.

PHP is today rarely used for heavy-math use cases.  It's mostly 
line-of-business applications, aka "over-engineered ways of concatenating 
strings out of a database."  Historically it's been too slow for that, which 
lead to no community around it, so no one did it, so no focused improvements in 
that area, so...  Infinite loop.  Python got most of that attention instead.

However, the JIT and FFI work have quite frankly very little use *other than* 
computation intensive (ie, math) use cases, and those were added without issue 
despite having APIs that are extremely crappy. :-)   So I don't understand the 
"math doesn't matter" argument either; if it doesn't matter, we wouldn't have 
needed JIT or FFI either.

I frankly think this is a red herring; it's a "I don't do heavy math work in 
PHP, so arguing that feature X makes PHP better for math carries no weight."  
It shouldn't be read as "PHP being good at complex computations is bad in 
itself."  (If anyone does actually believe that, I'd say speak up but I'd just 
tell you that you're wrong from the get-go, so maybe let's not pick that fight 
and leave it as a hypothetical. :-) )

> # Non-Breaking Engine Changes
>
> The way that equality and comparison evaluation is done in the engine makes
> it impossible for certain kinds of overloading to be done, even in
> extensions. This isn't because that was an intended restriction, I
> discussed this issue with CMB and provided a PR a few months ago to resolve
> this, however it has remained in limbo:
> https://github.com/php/php-src/pull/7973
>
> # Overall Vision
>
> I'm not sure at this point how voters think objects and operators should
> work together into the future. I'd like to see if anyone is willing to have
> high-level discussion about the ideas, instead of picking at the
> implementation or details of a particular RFC.
>
> Jordan

I am always down for high-level ideas discussions. :-P

As even the detractors noted, the previous RFC is probably the best design that 
could be done, given PHP's existing nature.  So aside