PHP 5.1

Marc Richards

21 years ago

Andi Gutmans wrote:

>
> Comments/Flames/Praises to this list :)
>

All praise PHP 5.1.  All praise PDO.

Marc

Stephan Schmidt

21 years ago

Hi,

Andi Gutmans schrieb:

> I believe both PDO and Date should be included in the default distro.

I'd like to see xmlreader be bundled as well. It's fast, easy to use and
still very powerful.

Stephan

--
http://www.php-tools.net
http://www.schst.net
http://pear.php.net

George Schlossnagle

21 years ago

On Feb 1, 2005, at 3:20 PM, Stephan Schmidt wrote:

> Hi,
>
> Andi Gutmans schrieb:
>> I believe both PDO and Date should be included in the default distro.
> I'd like to see xmlreader be bundled as well. It's fast, easy to use
> and still very powerful.

+1

George

Christian Stocker

21 years ago

On 1.2.2005 21:20 Uhr, Stephan Schmidt wrote:

> Hi,
>
> Andi Gutmans schrieb:
>
>> I believe both PDO and Date should be included in the default distro.
>
> I'd like to see xmlreader be bundled as well. It's fast, easy to use and
> still very powerful.

Very big +1 from me on that as well. XMLReader needs to be bundled, it's
far superior to sax aka ext/xml and widespread use won't hurt (but
that's just my 2 cents).

And Rob is working on better error reporting for the different XML
classes. I have no ideas, how "finished" that is. But we need that in
5.1, as well (I already told everyone, that 5.1 will have better error
reporting ;) ). He can certainly better tell you, how far he is with that.

chregu

>
> Stephan

--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60  | fax +41 1 240 56 71
http://www.bitflux.ch  |  chregu@bitflux.ch  |  gnupg-keyid 0x5CE1DECB

Andi Gutmans

21 years ago

Don't see a problem with that if it's release quality.

Andi

At 09:20 PM 2/1/2005 +0100, Stephan Schmidt wrote:

Rasmus Lerdorf

21 years ago

Andi Gutmans wrote:

> I believe both PDO and Date should be included in the default distro. As
> far as PDO is concerned I think for each DB if it is selected at
> configure time, the relevant PDO extension should also be enabled. So
> doing --with-oci8 should enable both ext/oci8 and ext/pdo_oci. This will
> give users more of a choice, give more exposure to PDO which is one of
> the most important features of 5.1 and of course, it doesn't really cost
> us very much except for having to do some configure hacking.

If I can get off my ass and get it finished up it would be good to get a
default input filtering extension in there as well.  We have not done
much to help people do proper input validation and although the hook for
it is in 5.0 I doubt anybody has actually used it yet.  I'll try to get
it into PECL in the next week or so for people to have a look.

-Rasmus

l0t3k

21 years ago

Andi,
i guess this means that proper serialization support for internal
classes will have to wait till 5.2 ?

l0t3k

Andi Gutmans

21 years ago

As time is very short, I suggest to discuss exactly what we want and then
to see if it's possible in a 5.1 time frame.
Can you give a short overview of what you had in mind and how the end-user
would be using the functionality?

Thanks,
Andi

At 02:10 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:

Rasmus Lerdorf

21 years ago

Andi Gutmans wrote:

> As time is very short, I suggest to discuss exactly what we want and
> then to see if it's possible in a 5.1 time frame.
> Can you give a short overview of what you had in mind and how the
> end-user would be using the functionality?

Well, I am not starting from scratch here.  I have code, it just needs a
bit of polishing.

But the general idea is to provide an optional filter that people can
enable in their ini file.  This will strip out any XSS, quotes, braces,
etc.  The actual list will need to be massaged a bit, and there will be
multiple filters so people can choose how strict to be by default.

At the same time a filter access function is provided.

eg.

$age  = pfilter(POST, 'age', FILTER_DIGITS);
$addr = pfilter(POST, 'addr', FILTER_ALNUM);
$body = pfilter(REQUEST, 'body', FILTER_TAGS);
$raw  = pfilter(COOKIE,'cook', FILTER_RAW);

We obviously can't turn on the input filter by default, but even without
the default filter enabled, providing a set of input filters for people
to use so they don't have to come up with complicated regular
expressions to check user input will go a long way to make it easier for
people to write safer applications.  Even people who actually take the
step to do input validation tend to get the validation wrong as we have
seen in a number of recent examples.

-Rasmus

Christian Schneider

21 years ago

Rasmus Lerdorf wrote:

> But the general idea is to provide an optional filter that people can
> enable in their ini file.  This will strip out any XSS, quotes, braces,

I assume this will include PHP functions to do the filtering as well?
(Forgive me if we already have this now, I haven't looked at 5.0 enough
yet :-))

> $age  = pfilter(POST, 'age', FILTER_DIGITS);
> $addr = pfilter(POST, 'addr', FILTER_ALNUM);
> $body = pfilter(REQUEST, 'body', FILTER_TAGS);
> $raw  = pfilter(COOKIE,'cook', FILTER_RAW);

Sounds like a good idea (even though the name pfilter reminds me too
much of packet filter :-)). A catch-all could be handy too, e.g.
pfilter(REQUEST, DEFAULT, FILTER_TAGS);
which filters anything not handled before. Surely you can come up with a
better interface but I hope you get the idea. Being able to define a
default filter but still override it for certain variables is what I
mean. (Also important would be that FILTER_TAGS is more robust than
strip_tags which has some loopholes IIRC)

I agree that making input validation (or filtering) easy is important to
help people write safer code. I once wrote a validator in PHP which
allowed me to specify allowable tags including attributes and regular
expression for the attribute values but it required the input to be
XML/XHTML which might be a bit too harsh for most people.

A bit off-topic: I'm sure variable tainting has been discussed before,
can some give the final opinion, was it found unsuitable/too much
work/too inefficient or was it just post-poned (maybe indefinitely)?

- Chris

Rasmus Lerdorf

21 years ago

Christian Schneider wrote:

> Rasmus Lerdorf wrote:
>
>> But the general idea is to provide an optional filter that people can
>> enable in their ini file.  This will strip out any XSS, quotes, braces,
>
>
> I assume this will include PHP functions to do the filtering as well?
> (Forgive me if we already have this now, I haven't looked at 5.0 enough
> yet :-))

Right,a function to filter user data through any of the filters will be
provided as well.

>> $age  = pfilter(POST, 'age', FILTER_DIGITS);
>> $addr = pfilter(POST, 'addr', FILTER_ALNUM);
>> $body = pfilter(REQUEST, 'body', FILTER_TAGS);
>> $raw  = pfilter(COOKIE,'cook', FILTER_RAW);
>
>
> Sounds like a good idea (even though the name pfilter reminds me too
> much of packet filter :-)). A catch-all could be handy too, e.g.
> pfilter(REQUEST, DEFAULT, FILTER_TAGS);

I just made up the pfilter name.  I really don't care what it is called.
Figured filter() was a bit too generic and likely to step on existing
user-space functions out there.

> which filters anything not handled before. Surely you can come up with a
> better interface but I hope you get the idea. Being able to define a
> default filter but still override it for certain variables is what I
> mean. (Also important would be that FILTER_TAGS is more robust than
> strip_tags which has some loopholes IIRC)

strip_tags only has loopholes if you allow some tags through.  But yes,
this would be a very strict get rid of all tags filter and it needs to
be charset aware.

> A bit off-topic: I'm sure variable tainting has been discussed before,
> can some give the final opinion, was it found unsuitable/too much
> work/too inefficient or was it just post-poned (maybe indefinitely)?

It is really hard to do this correctly.  Most user data in a web app is
multi-purpose in the sense that it is often both displayed and inserted
into a database, for example.  The untaint rules are vastly different
for these two purposes.  Throw in a few more and you have a mess on your
hands.  Just because you untainted it for one purpose doesn't mean it is
safe for another, so I don't really see how a single taint flag can be
all that effective.  I would rather see context-specific access function
that retrieves the data for a specific purpose.  In this case
implemented by calling pfilter with a given filter.

And just to clarify, since I added the hook to do this long ago, there
aren't actually any PHP changes needed.  It can be completely handled in
a pecl extension.  It just becomes a matter of whether/when to include
it with PHP.

-Rasmus

Jochem Maas

21 years ago

>> $raw  = pfilter(COOKIE,'cook', FILTER_RAW);
>
>
> Sounds like a good idea (even though the name pfilter reminds me too
> much of packet filter :-)). A catch-all could be handy too, e.g.
> pfilter(REQUEST, DEFAULT, FILTER_TAGS);

maybe rfilter() - as in 'request filter'?

Andi Gutmans

21 years ago

At 01:31 AM 2/2/2005 +0100, Jochem Maas wrote:

>>>$raw  = pfilter(COOKIE,'cook', FILTER_RAW);
>>
>>Sounds like a good idea (even though the name pfilter reminds me too much
>>of packet filter :-)). A catch-all could be handy too, e.g.
>>pfilter(REQUEST, DEFAULT, FILTER_TAGS);
>
>maybe rfilter() - as in 'request filter'?

Standard today is [common prefix]_functionname()

So please don't suggest non-standard conforming names :)

Andi

Jeff Moore

21 years ago

On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:

> But the general idea is to provide an optional filter that people can
> enable in their ini file.  This will strip out any XSS, quotes,
> braces, etc.

I hate to see more ini options.  They make it more difficult to write
programs that work under a variety of configurations and more difficult
to integrate programs written for different configurations.  I would
like to less ini file variability in the wild, not more.

It seems to me like only the application knows what is valid data.
Trying to bolt on input checking to existing applications from the
outside looks like it would just break applications, perhaps in subtle
and difficult to detect ways.

One example would be that applications which display back form values
upon validation failure would be sending back modified values.  This
can be disconcerting to the user.  The user may not even notice that
what they typed was silently modified to be something else.

Doing this from the ini file just seems like another kind of
magic_quotes_gpc to me.  I am not a fan of magic.

If ini file based filtering causes too many problems to turn on in
general, then what good is having it?  If ini file based filtering
becomes too specific to an individual application, then why not just
let the application handle it?  It seems like a fine line to walk.

I am wary of an ini file based input filtering.

> echo filter(GET,'foo',FILTER_NUMBER);

A set of easy to use and easy to find whitelist oriented filtering and
validation functions is a great idea.

Eventually, someone is going to want to start adding parameters to
control the filtering.  This would be easier with individual functions
for individual types.  Also, the filters would be more useful if they
were de-coupled from the input mechanism.

What about:

echo filter_number($_GET['foo']);
echo filter_string($str);  // Perhaps same thing as strip_tags with no
$allowed_tags, but white list oriented naming.
echo filter_html($str, $allowed_tags_and_attributes);  // improved
strip_tags
etc.

Also perhaps something like this for registering input filters:

register_filter(GET, ALL, 'trim');
register_filter(GET, 'foo', 'filter_number');
register_filter(GET, 'bar', 'filter_html',
$allowed_tags_and_attributes);

echo $_GET['foo'];
echo $_GET['bar'];

If there had to be a ini file option, then perhaps something taint-like:

block_unfiltered_input = 1

With this option, superglobals that didn't have filters registered
would simply be NULL.  An option like this has to be able to be
modified at runtime.  something like:

echo $_GET['foo'];   //   'bar'
ini_set('block_unfiltered_input', TRUE);
echo $_GET['foo'];  // NULL

I have no idea how super globals are implemented, so I don't know if
this is even possible.  These are just some additional ideas.

Rasmus Lerdorf

21 years ago

Jeff Moore wrote:

>
> On Feb 1, 2005, at 5:41 PM, Rasmus Lerdorf wrote:
>
>> But the general idea is to provide an optional filter that people can
>> enable in their ini file.  This will strip out any XSS, quotes,
>> braces, etc.
>
>
> I hate to see more ini options.  They make it more difficult to write
> programs that work under a variety of configurations and more difficult
> to integrate programs written for different configurations.  I would
> like to less ini file variability in the wild, not more.
>
> It seems to me like only the application knows what is valid data.
> Trying to bolt on input checking to existing applications from the
> outside looks like it would just break applications, perhaps in subtle
> and difficult to detect ways.

We have seen definitively that many application writers do not know how
to properly validate data.  And yes, it is another ini thing to worry
about, and yes it will be painful, but I don't think we can continue to
ignore this.  I also think that people who actually write good and
secure web apps in PHP won't have too many problems with this.  It will
just be an additional tool they can use if it is available.  For people
who don't know what they are doing or don't care about security, it may
very well break their applications, but those applications most likely
should be broken.

Pick 10 random PHP apps out there and go through them.  With very very
few exceptions 10 out of 10 will be insecure.  And the blame here is not
just on the developers of those applications, we are partially to blame
for not providing enough tools and guidelines.  This is what I am trying
to rectify with minimum impact to the existing code and the way people
do things.  Some of your suggestions are good, but some just aren't
feasible.  For example, it would be difficult to implement your idea of
only letting data through if a filter was assigned to it and having
those filter assignments happen in the scripts themselves since that is
too late in the game.  It could be hacked, but it would be ugly and
complex.  Having just a single optional default filter per request is
simpler to manage and implement.

-Rasmus

Jeff Moore

21 years ago

On Feb 2, 2005, at 3:53 PM, Rasmus Lerdorf wrote:

> We have seen definitively that many application writers do not know
> how to properly validate data.  And yes, it is another ini thing to
> worry about, and yes it will be painful, but I don't think we can
> continue to ignore this.  I also think that people who actually write
> good and secure web apps in PHP won't have too many problems with
> this.  It will just be an additional tool they can use if it is
> available.  For people who don't know what they are doing or don't
> care about security, it may very well break their applications, but
> those applications most likely should be broken.

I absolutely agree that a problem exists.  However, I am not sure that
an optional external filtering solution will solve the problem.
Especially if the option breaks too much stuff for most people to turn
it on.

On the other hand, just the existence of the option, even if rarely
used will still result in obscure bug reports and a steeper learning
curve.

I would like to be wrong.

On Feb 4, 2005, at 4:00 AM, Rasmus Lerdorf wrote:

> And everyone here understands that &{ needs to be stripped or entitied
> as well, right?  How many non-internals folks do you think know that?

Which is why whitelists for input are better than blacklists.  If a
strict global blacklist oriented filter causes the programmer to bypass
it and go for the raw input, then they are in the same boat regarding
this stuff.

Independently of the external filtering, a set of standard whitelist
oriented filtering functions would be a good idea.

There may also be some other areas where quoting requirements and
filtering requirements might be made more obvious.

For example, if you use external input inside the replacement parameter
of preg_replace, you have to quote it.  However, many people don't
realize that, or that the quoting rules for the replacement parameter
are different than the quoting rules for the search pattern parameter.
A preg_replacement_quote function might highlight this issue.

Andi Gutmans

21 years ago

At 12:53 PM 2/2/2005 -0800, Rasmus Lerdorf wrote:

>Pick 10 random PHP apps out there and go through them.  With very very few
>exceptions 10 out of 10 will be insecure.  And the blame here is not just
>on the developers of those applications, we are partially to blame for not
>providing enough tools and guidelines.  This is what I am trying to
>rectify with minimum impact to the existing code and the way people do
>things.  Some of your suggestions are good, but some just aren't
>feasible.  For example, it would be difficult to implement your idea of
>only letting data through if a filter was assigned to it and having those
>filter assignments happen in the scripts themselves since that is too late
>in the game.  It could be hacked, but it would be ugly and
>complex.  Having just a single optional default filter per request is
>simpler to manage and implement.

We could filter the superglobals at run-time. There are two options:
a) Go over the super globals and filter each one.
b) If the superglobal JIT thingy works (which I think it does) then you
could set a flag before using the first superglobal and it would happen JIT.

I'd probably prefer (a) though.

Andi

Andi Gutmans

21 years ago

I definitely like the idea and thing it's important.
I think as far as the filter functions are concerned this is a good way to
go (although I'd change the function name but that's no biggy,
filter_input?). I very much see how filter_input(POST, "email",
FILTER_EMAIL) is easier as opposed to finding the right regex for emails
and it's great re-use.

As far as the INI is concerned, that's probably much more complicated
because it would probably have to be on a per-script basis. Did you want to
finalize that also for 5.1? What's your thinking on what it would look
like? Or where you just thinking of a more general filter that will
globally get rid of certain things like XSS, quotes, etc.?

Andi

At 02:41 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:

Rasmus Lerdorf

21 years ago

Andi Gutmans wrote:

> I definitely like the idea and thing it's important.
> I think as far as the filter functions are concerned this is a good way
> to go (although I'd change the function name but that's no biggy,
> filter_input?). I very much see how filter_input(POST, "email",
> FILTER_EMAIL) is easier as opposed to finding the right regex for emails
> and it's great re-use.

Yeah, I really don't care what the name of the function is.  Wanted to
try to keep it somewhat short since it might need to be typed a lot.

> As far as the INI is concerned, that's probably much more complicated
> because it would probably have to be on a per-script basis. Did you want
> to finalize that also for 5.1? What's your thinking on what it would
> look like? Or where you just thinking of a more general filter that will
> globally get rid of certain things like XSS, quotes, etc.?

I don't actually see it as a per-script thing.  Obviously the ini would
be per-dir Apache configurable, but I see this as being something set
across the board on a dedicated server that defines the security policy
of that server.  Shared servers are most likely not going to be able to
settle on a single security policy so they would either only enable it
for certain vhosts or leave it off altogether.  As someone suggested, if
the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or
something to that effect then an individual script could in one shot
filter all GET data even if the default ini filter wasn't in place.  The
main reason for the default ini filter is to be able to deploy code
other people have written and be somewhat safer without having to go
through each line of the application trying to figure out where to
filter stuff.  If you just filter everything flowing into the
application you have added a decent amount of safety to untrusted code.
It may very well break the code, but this is a saner starting point.
This way you track down stuff that doesn't work and think about which
filter to apply in each situation as opposed to starting from a wide
open position and reading through all the code looking for places to
restrict things.

-Rasmus

Shane Caraveo

21 years ago

Rasmus Lerdorf wrote:

> Andi Gutmans wrote:
>
>> I definitely like the idea and thing it's important.
>> I think as far as the filter functions are concerned this is a good
>> way to go (although I'd change the function name but that's no biggy,
>> filter_input?). I very much see how filter_input(POST, "email",
>> FILTER_EMAIL) is easier as opposed to finding the right regex for
>> emails and it's great re-use.
>
>
> Yeah, I really don't care what the name of the function is.  Wanted to
> try to keep it somewhat short since it might need to be typed a lot.
>

I thought my suggestion the other week was pretty good....safe_filter :-)

Shane

Rasmus Lerdorf

21 years ago

Shane Caraveo wrote:

> I thought my suggestion the other week was pretty good....safe_filter :-)

Hey, no snarky comments from the peanut gallery please!  ;) No PHP
function  or feature will ever be called safe* again.

-Rasmus

Derick Rethans

21 years ago

On Tue, 1 Feb 2005, Rasmus Lerdorf wrote:

> Shane Caraveo wrote:
> > I thought my suggestion the other week was pretty good....safe_filter :-)
>
> Hey, no snarky comments from the peanut gallery please!  ;) No PHP
> function  or feature will ever be called safe* again.

I totally agree with that.

Derick

Christian Schneider

21 years ago

Rasmus Lerdorf wrote:

> I don't actually see it as a per-script thing.  Obviously the ini would
> be per-dir Apache configurable, but I see this as being something set
> across the board on a dedicated server that defines the security policy
> of that server.  Shared servers are most likely not going to be able to

Uh, that's a big goal but also asking for trouble. As you pointed out
there is a different rule on what's safe for a specific input variable
based on what it's used for (e.g. SQL, output, shell arg) and what's
not. Wouldn't one have to set up default filters for every possible use
to be safe then, i.e. a combination of all filters?

Another major point would be to handle UTF8 properly, something which is
not easily handled by regular expressions, right?

- Chris

Nick Loeve

21 years ago

> Rasmus Lerdorf wrote:
>
>> I don't actually see it as a per-script thing.  Obviously the ini
>> would be per-dir Apache configurable, but I see this as being
>> something set across the board on a dedicated server that defines the
>> security policy of that server.
>

Isn't that something you can use mod_security for? I don't know of the
availability of that module on a standard host, but on a dedicated
server you could install it.

>> Shared servers are most likely not going to be able to
>

Cheers
Nick Loeve

Jan Kneschke

21 years ago

On Wed, Feb 02, 2005 at 11:23:23AM +1100, Nick Loeve wrote:

>
> >Rasmus Lerdorf wrote:
> >
> >>I don't actually see it as a per-script thing.  Obviously the ini
> >>would be per-dir Apache configurable, but I see this as being
> >>something set across the board on a dedicated server that defines the
> >>security policy of that server.
> >
> Isn't that something you can use mod_security for? I don't know of the
> availability of that module on a standard host, but on a dedicated
> server you could install it.

There are other servers out there like apache and mod_security is not
installed on enough servers to call it 'standard'.

> Cheers
> Nick Loeve

Jan

--
Jan Kneschke                                     http://jan.kneschke.de/
Perhaps you want to say 'thank you, jan':    http://jk.123.org/wishlist/

Rasmus Lerdorf

21 years ago

Nick Loeve wrote:

>
>> Rasmus Lerdorf wrote:
>>
>>> I don't actually see it as a per-script thing.  Obviously the ini
>>> would be per-dir Apache configurable, but I see this as being
>>> something set across the board on a dedicated server that defines the
>>> security policy of that server.
>>
>>
> Isn't that something you can use mod_security for? I don't know of the
> availability of that module on a standard host, but on a dedicated
> server you could install it.

No, because we don't actually want to lose the raw data.  We need to
save the raw data internally in PHP and make it available via the filter
function.  So if a strict default ini filter is enabled you would have
something like this:

GET /script.php?foo=<xss hack>123 Hello</xss hack>

echo $_GET['foo'];

Would output:  123 Hello

echo filter(GET,'foo',FILTER_RAW);

Would output: <xss hack>123 Hello</xss hack>

echo filter(GET,'foo',FILTER_NUMBER);

Would output:  123

The extra spaces are intentional.  Stripped characters are replaced with
a single space.  So if you had: abc<font size=10>def
You would end up with: abc def

-Rasmus

Nick Loeve

21 years ago

Rasmus Lerdorf wrote:

> Nick Loeve wrote:
>
>>
>>> Rasmus Lerdorf wrote:
>>>
>>>> I don't actually see it as a per-script thing.  Obviously the ini
>>>> would be per-dir Apache configurable, but I see this as being
>>>> something set across the board on a dedicated server that defines
>>>> the security policy of that server.
>>>
>>>
>>>
>> Isn't that something you can use mod_security for? I don't know of
>> the availability of that module on a standard host, but on a
>> dedicated server you could install it.
>
>
> No, because we don't actually want to lose the raw data.  We need to
> save the raw data internally in PHP and make it available via the
> filter function.  So if a strict default ini filter is enabled you
> would have something like this:
>
>   GET /script.php?foo=<xss hack>123 Hello</xss hack>
>
>   echo $_GET['foo'];
>
> Would output:  123 Hello
>
>   echo filter(GET,'foo',FILTER_RAW);
>
> Would output: <xss hack>123 Hello</xss hack>
>
>   echo filter(GET,'foo',FILTER_NUMBER);
>
> Would output:  123
>
> The extra spaces are intentional.  Stripped characters are replaced
> with a single space.  So if you had: abc<font size=10>def
> You would end up with: abc def
>
> -Rasmus

That sounds really cool. I have never used mod_security very much, so i
didn't realise it killed the data.

Would it be able to take user-defined functions as a filter type
alternative?

Cheers
Nick Loeve

Ilia A.

21 years ago

Given that we'd always need to store the raw request data in memory, can
we provide some mechanism of accessing it that does not require a
function call? If working with integer or floating point based data it
is much faster and simpler to just do (int)/(float) cast rather then
executing function calls.

Ilia

Rasmus Lerdorf wrote:

Rasmus Lerdorf

21 years ago

Ilia Alshanetsky wrote:

> Given that we'd always need to store the raw request data in memory, can
> we provide some mechanism of accessing it that does not require a
> function call? If working with integer or floating point based data it
> is much faster and simpler to just do (int)/(float) cast rather then
> executing function calls.

I suppose, but as far as I am concerned it should be the rare case where
someone uses the raw data directly.  All user input should be validated
before being used.  Unlike today where input validation is the rare
case.  If you have your own validation you want to do, then there should
be a facility to pass a user function to the filter function.

A further question becomes what to do with Apache-populated variables.
Things like $_SERVER['REQUEST_URI'] and $_SERVER['PATH_INFO'] could have
nasty stuff in them.  Filtering those as well isn't hard, of course.

Looking at my code here, it would actually be trivial to expose the raw
data as superglobals, but what do we achieve then?  We are simply
renaming $_GET to $_GET_RAW or something like that?  If you don't want
any filtering to be done by default, simply don't turn it on.

-Rasmus

Ilia A.

21 years ago

> Looking at my code here, it would actually be trivial to expose the raw
> data as superglobals, but what do we achieve then?  We are simply
> renaming $_GET to $_GET_RAW or something like that?  If you don't want
> any filtering to be done by default, simply don't turn it on.

In many cases it may not be possible to turn off automatic input filter,
because of limited access.

Ilia

Andi Gutmans

21 years ago

Yeah I agree. I think additional superglobals are superfluous.
Not turned on $_GET behaves the same. Turned on then $_GET would be
filtered and you'd use a function call to get to the raw data. I don't see
this as a problem and am not concerned about performance.

Andi

At 08:25 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:

Ryan King

21 years ago

On Feb 1, 2005, at 4:55 PM, Rasmus Lerdorf wrote:

> Nick Loeve wrote:
>>> Rasmus Lerdorf wrote:
>>>
>>>> I don't actually see it as a per-script thing.  Obviously the ini
>>>> would be per-dir Apache configurable, but I see this as being
>>>> something set across the board on a dedicated server that defines
>>>> the security policy of that server.
>>>
>>>
>> Isn't that something you can use mod_security for? I don't know of
>> the availability of that module on a standard host, but on a
>> dedicated server you could install it.
>
> No, because we don't actually want to lose the raw data.  We need to
> save the raw data internally in PHP and make it available via the
> filter function.  So if a strict default ini filter is enabled you
> would have something like this:
>
>   GET /script.php?foo=<xss hack>123 Hello</xss hack>
>
>   echo $_GET['foo'];
>
> Would output:  123 Hello
>
>   echo filter(GET,'foo',FILTER_RAW);
>
> Would output: <xss hack>123 Hello</xss hack>
>
>   echo filter(GET,'foo',FILTER_NUMBER);
>
> Would output:  123

This makes me think it would be nice to have a way to test and see if
anything was caught by the filters.

I guess:

if (!(filter(GET,'foo',FILTER_RAW);))
//then something was caught?

-ryan

--
http://theryanking.com/blog

Andi Gutmans

21 years ago

Yep agreed. We should have something standard in PHP.
And never forget, PHP is cross-web server:)

Andi

At 04:55 PM 2/1/2005 -0800, Rasmus Lerdorf wrote:

Stefan Esser

21 years ago

Hi,

> Isn't that something you can use mod_security for? I don't know of the
> availability of that module on a standard host, but on a dedicated
> server you could install it.

mod_security (ehmm mod_illusion) is unable to protect PHP applications
because it has more holes than swiss cheese.

Stefan

Ryan King

21 years ago

On Feb 1, 2005, at 4:23 PM, Nick Loeve wrote:

>
>> Rasmus Lerdorf wrote:
>>
>>> I don't actually see it as a per-script thing.  Obviously the ini
>>> would be per-dir Apache configurable, but I see this as being
>>> something set across the board on a dedicated server that defines
>>> the security policy of that server.
>>
> Isn't that something you can use mod_security for? I don't know of the
> availability of that module on a standard host, but on a dedicated
> server you could install it.

I believe the host I use, Text Drive (http://textdrive.com) uses it.
And I can speak highly enough about them.

-ryan

--
http://theryanking.com/blog

Rasmus Lerdorf

21 years ago

Christian Schneider wrote:

> Rasmus Lerdorf wrote:
>
>> I don't actually see it as a per-script thing.  Obviously the ini
>> would be per-dir Apache configurable, but I see this as being
>> something set across the board on a dedicated server that defines the
>> security policy of that server.  Shared servers are most likely not
>> going to be able to
>
>
> Uh, that's a big goal but also asking for trouble. As you pointed out
> there is a different rule on what's safe for a specific input variable
> based on what it's used for (e.g. SQL, output, shell arg) and what's
> not. Wouldn't one have to set up default filters for every possible use
> to be safe then, i.e. a combination of all filters?

Well, if you set a global filter you set an extremely strict one.  Like
only letting a-z through or the equivalent in your charset, for example.
Want a number?  Tough, call the filter function to get at it.  The
idea is to force people to think about how to filter each piece of data
they need, and if they forget one it will still work, but what gets
through will be extremely limited.

> Another major point would be to handle UTF8 properly, something which is
> not easily handled by regular expressions, right?

The preg* functions support UTF8.  But yes, the filters need to
understand charsets correctly.

-Rasmus

Christian Schneider

21 years ago

Rasmus Lerdorf wrote:

> Well, if you set a global filter you set an extremely strict one.  Like
> only letting a-z through or the equivalent in your charset, for example.
>  Want a number?  Tough, call the filter function to get at it.  The idea

Ah, ok, you can still get the original data but you have to do it
manually. Will break most applications (email-addresses would need to
allow a bit more than that already but that's still safe, passwords
might be a bit trickier).

> The preg* functions support UTF8.  But yes, the filters need to
> understand charsets correctly.

Stupid question: Is it safe to pass a variable containing UTF8 to a
ASCII function like exec()? I think to remember that the encoding makes
sure that the encoding ensures that none of the ASCII characters will be
contained in the string as part of a multibyte encoded character, right?

- Chris

Peter Brodersen

21 years ago

On Wed, 02 Feb 2005 02:00:12 +0100, in php.internals
cschneid@cschneid.com (Christian Schneider) wrote:

>Stupid question: Is it safe to pass a variable containing UTF8 to a
>ASCII function like exec()? I think to remember that the encoding makes
>sure that the encoding ensures that none of the ASCII characters will be
>contained in the string as part of a multibyte encoded character, right?

Well, if the UTF-8 data is valid (which I suppose would be validated
the same was as any UTF-8-supported function validates it) then all
bytes that make up the UTF-8-character will be in range of 0x80 and
0xF7.

That's the nice thing about UTF-8 - no character with code points
above 128 will produce bytes where the uppermost bit is zero (0x00 to
0x7F)

--
- Peter Brodersen

Derick Rethans

21 years ago

On Wed, 2 Feb 2005, Christian Schneider wrote:

> Rasmus Lerdorf wrote:
> > I don't actually see it as a per-script thing.  Obviously the ini would
> > be per-dir Apache configurable, but I see this as being something set
> > across the board on a dedicated server that defines the security policy
> > of that server.  Shared servers are most likely not going to be able to
>
> Uh, that's a big goal but also asking for trouble. As you pointed out
> there is a different rule on what's safe for a specific input variable
> based on what it's used for (e.g. SQL, output, shell arg) and what's
> not. Wouldn't one have to set up default filters for every possible use
> to be safe then, i.e. a combination of all filters?
>
> Another major point would be to handle UTF8 properly, something which is
> not easily handled by regular expressions, right?

preg supports UTF-8 just fine, but UTF-8 is not the only encoding in use
(think about most of China ;-) so you have a point. Simply, in those
cases people can simply choose not to filter at all, or we can provide
this ourselves later when we have real unicode support.

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Andi Gutmans

21 years ago

The only problem is that this is an extension so it would probably have a
few functions:
filter_input()
filter_validate()
filter_foobar()

Maybe we were only discussing one method but it's likely for others to follow.

I thinks safe_* is a bit general but then again, although naming is the
hardest part of computer science, what the extension does is the most
important part :)

Andi

At 04:07 PM 2/1/2005 -0800, Shane Caraveo wrote:

Sean Coates

21 years ago

Rasmus Lerdorf wrote:

> As someone suggested, if
> the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or
> something to that effect then an individual script could in one shot
> filter all GET data even if the default ini filter wasn't in place.

Might I suggest:

foo_filter($type, $keys, FILTER_TAGS);

where $type and $keys are strings (as originally intended), or they
could be arrays of types and keys (similar to how str_replace works).

//example
foo_filter(array(FOO_GET, FOO_POST, FOO_ENV), array('bar','baz'),
FOO_TYPE_TAGS);

This way we could easily filter a large number (or all) keys from many
request types in one command:

/* filter all tags from all get vars */
foo_filter(FOO_GET, array_keys($_GET), FOO_TYPE_TAGS);
//and
/* filter all tags from all POST vars, except $_POST['baz'];
foo_filter(FOO_POST, array_diff(array_keys($_POST), array('baz')),
FOO_TYPE_TAGS);

Would also be nice if the third parameter was a bitfield:
foo_filter(FOO_POST, 'bar', FOO_TYPE_ALL &~ FOO_TYPE_QUOTES);

S

Ryan King

21 years ago

On Feb 1, 2005, at 8:10 PM, Sean Coates wrote:

> Rasmus Lerdorf wrote:
>> As someone suggested, if the filter function could do $GET =
>> filt(GET,'*',FILTER_TAGS) or something to that effect then an
>> individual script could in one shot filter all GET data even if the
>> default ini filter wasn't in place.
>
> Might I suggest:
>
> foo_filter($type, $keys, FILTER_TAGS);
>
> where $type and $keys are strings (as originally intended), or they
> could be arrays of types and keys (similar to how str_replace works).
>
> //example
> foo_filter(array(FOO_GET, FOO_POST, FOO_ENV), array('bar','baz'),
> FOO_TYPE_TAGS);
>
> This way we could easily filter a large number (or all) keys from many
> request types in one command:
>
> /* filter all tags from all get vars */
> foo_filter(FOO_GET, array_keys($_GET), FOO_TYPE_TAGS);
> //and
> /* filter all tags from all POST vars, except $_POST['baz'];
> foo_filter(FOO_POST, array_diff(array_keys($_POST), array('baz')),
> FOO_TYPE_TAGS);
>
> Would also be nice if the third parameter was a bitfield:
> foo_filter(FOO_POST, 'bar', FOO_TYPE_ALL &~ FOO_TYPE_QUOTES);

Wouldn't this make it more difficult to be extended by a user. The way
I imagine it working now is like this:


function my_filter ()
{
//blah blah
}

define('FOO_MY_FILTER', 'myfilter');

foo_filter(FOO_POST, 'bar', FOO_MY_FILTER);

Then the constant really just becomes a callback and I can add anything
in that I want.

Maybe?

-ryan

--
http://theryanking.com/blog

Sean Coates

21 years ago

Ryan King wrote:

> Then the constant really just becomes a callback and I can add anything
> in that I want.

IMO, this is what array_walk(...) is for.
Especially if pre- and post-filter $_SUPERGLOBALs are made available.

S

Ryan King

21 years ago

On Feb 1, 2005, at 9:27 PM, Sean Coates wrote:

> Ryan King wrote:
>> Then the constant really just becomes a callback and I can add
>> anything in that I want.
>
> IMO, this is what array_walk(...) is for.
> Especially if pre- and post-filter $_SUPERGLOBALs are made available.

I'm not exactly sure what you're saying here. Are you saying that
instead of creating my own filter, I just array_walk over the
superglobals with my filter?

If so, that's definitely doable, but I like the idea of being able to
add my own filter, because that keeps all the superglobal-cleaning code
together (somewhat).

I dunno, what do you think?

-ryan

--
http://theryanking.com/blog

Xuefer Tinys

21 years ago

more choices:
foo_bar(string $key or array $keys, int or string $how)
bar can be one of get,post,request,env,server
foo may be filter? ifilter? (i for input)

may foo be empty? _get _post etc..
$how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
for raw data same as $_GET['abc'] before. it's just simple
and it would make user easy to migrate their thinking, not just the script
we had made too much changes: $abc -> $HTTP_GET_VARS['abc'] ->
$_GET['abc'] -> _GET('abc') or filter_xxx(GET...)

On Tue, 1 Feb 2005 21:21:47 -0800, Ryan King <ryansking@mac.com> wrote:

Rasmus Lerdorf

21 years ago

Xuefer Tinys wrote:

> more choices:
> foo_bar(string $key or array $keys, int or string $how)
> bar can be one of get,post,request,env,server
> foo may be filter? ifilter? (i for input)
>
> may foo be empty? _get _post etc..
> $how is default to FILTER_RAW so we have _get("abc") and _GET("abc")
> for raw data same as $_GET['abc'] before. it's just simple
> and it would make user easy to migrate their thinking, not just the script
> we had made too much changes: $abc -> $HTTP_GET_VARS['abc'] ->
> $_GET['abc'] -> _GET('abc') or filter_xxx(GET...)

I don't think you understand.  The idea here is not to change anything.
Changing to _GET('abc') with a default raw filter would be completely
pointless.

People would still be using $_GET['abc'] just like before.  If, and only
if a default filter is in place in the ini file, then this value is
filtered.  Depending on the filter this just means that the app will run
exactly like before, except tags would be stripped, for example.

If no default filter is in place, which would be the most common case as
it wouldn't be turned on by default, then this extension in no way
affects existing code.  In this case all it provides are a set of easy
to use data filtering functions that an application can make use of
instead of trying to dream up regular expressions to handle all the
various cases.  I think we have seen over the past couple of years that
this is a very hard problem for developers to tackle in each and every
PHP application and the whole point of PHP is to tackle these hard
problems and provide an easy solution.

Anyway, I'll try to get some code into CVS this weekend and you guys can
have a look.

-Rasmus

Derick Rethans

21 years ago

On Tue, 1 Feb 2005, Sean Coates wrote:

> Rasmus Lerdorf wrote:
> > As someone suggested, if
> > the filter function could do $GET = filt(GET,'*',FILTER_TAGS) or
> > something to that effect then an individual script could in one shot
> > filter all GET data even if the default ini filter wasn't in place.
>
> Might I suggest:
>
> foo_filter($type, $keys, FILTER_TAGS);
>
> where $type and $keys are strings (as originally intended), or they
> could be arrays of types and keys (similar to how str_replace works).

It's not a filter afaics... the idea was to use:

$variable = funcname(SUPERGLOBAL, 'varname', filtertype);

this function should not modify any existing variable, but just be used
to extract variables from the request data. That would make the most
sense, and it's the most readable way (of being aware of those issues).

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Andi Gutmans

21 years ago

When you mean support, basically it's just adding serialize/unserialize
callbacks right? Doesn't mean all extensions need to implement them?

Andi

At 05:21 PM 2/1/2005 -0500, l0t3k wrote:

George Schlossnagle

21 years ago

On Feb 1, 2005, at 5:36 PM, Andi Gutmans wrote:

> When you mean support, basically it's just adding
> serialize/unserialize callbacks right? Doesn't mean all extensions
> need to implement them?

Those can be 'bugfixes' in point releases?

George

Andi Gutmans

21 years ago

Yeah, that's what I meant. I.e. add them to not screw up the API afterwards
but leave it up to the extensions to implement the callbacks when the
authors have time pre or post 5.1.

Andi

At 05:37 PM 2/1/2005 -0500, George Schlossnagle wrote:

l0t3k

21 years ago

Andi,
good enough for me.

"Andi Gutmans" <andi@zend.com> wrote in message
news:5.1.0.14.2.20050201144108.0272f490@localhost...

J Smith

21 years ago

Andi Gutmans wrote:

> Hey,
>
> I just heard from Wez that PDO is in very advanced stages now (ready for
> beta). I would like to start the PHP 5.1 release process. Due to the lack
> of testing both the new engine VM and PDO have received I would like to
> start with a beta process so that we get feedback.
>
> I know there are still some fixes that need to be applied both in the
> engine and in extensions so I would like to release a beta on March 1st (a
> month from today).
> Derick also mentioned that his new very much needed Date
> extension will be ready by that date.
>
> I believe both PDO and Date should be included in the default distro. As
> far as PDO is concerned I think for each DB if it is selected at configure
> time, the relevant PDO extension should also be enabled. So doing
> --with-oci8 should enable both ext/oci8 and ext/pdo_oci. This will give
> users more of a choice, give more exposure to PDO which is one of the most
> important features of 5.1 and of course, it doesn't really cost us very
> much except for having to do some configure hacking.
>
> Comments/Flames/Praises to this list :)
>
> Andi

Seems every time I get ready to finally commit the new browscap stuff that
I've been sitting on for 5.1 since forever, something always comes up and
it gets on the backburner.

Since I've been out of the loop for so long (still passively reading the
lists, but I haven't had much time to actively participate in much of
anything of late) perhaps someone else should commit this stuff. There are
a few added files and a patch and that's pretty much it. I've tested
against a copy of HEAD I just checked out on linux and Win2k with VS6, and
it seems to work okay, although I haven't tried any of the Visual Studio
workspaces or anything, so they may assplode, I don't know.

The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
It's not exactly new VM exciting or PDO exciting (which, if you're reading
this Wez, looks quite nice), but browser detection is something I think PHP
should do well. It is primarily a web scripting language, after all.

J

Gareth Ardron

21 years ago

Jay Smith wrote:

>
>The patch is at http://bugs.tutorbuddy.com/download/browscap.patch.tar.gz .
>It's not exactly new VM exciting or PDO exciting (which, if you're reading
>this Wez, looks quite nice), but browser detection is something I think PHP
>should do well. It is primarily a web scripting language, after all.
>
>

Personally, anything that means I can remove the odd bit of shonky
javascript would be welcome.

Ilia A.

21 years ago

Jay,

I've noticed that you're still using the ini parser in this new code,
would it not be easier and allow for greater code re-use to use the CSV
database and the underlying fgetcsv code?

Ilia

Jay Smith wrote:

J Smith

21 years ago

Ilia Alshanetsky wrote:

> Jay,
>
> I've noticed that you're still using the ini parser in this new code,
> would it not be easier and allow for greater code re-use to use the CSV
> database and the underlying fgetcsv code?
>
> Ilia
>

Hi Ilia, long time no irc...

It probably would be a lot easier to go with the CSV parser as far as code
maintenance is concerned, but I think the wtf factor may make it more
annoying than it's worth. I can already picture bug reports saying "my
browscap.ini file isn't being read any more, what gives". I'm sure it would
be no where close to as bad as register_globals, but still, it's some
unnecessary BC breakage that will probably be more trouble than it's worth.

This is a x.1 release, so I guess this would be the time to do a semi-major
change like this, but I personally don't think it's warranted from the
users perspective. Just an unnecessary (albeit quite minor) hurdle to
upgrading to 5.1, imho.

J

Andi Gutmans

21 years ago

Any volunteers to review and commit this?

At 07:51 PM 2/1/2005 -0500, Jay Smith wrote:

Marcus Börger

21 years ago

Hello Andi,

Tuesday, February 1, 2005, 8:26:15 PM, you wrote:

> Hey,

> I just heard from Wez that PDO is in very advanced stages now (ready for beta).
> I would like to start the PHP 5.1 release process. Due to the lack of
> testing both the new engine VM and PDO have received I would like to start
> with a beta process so that we get feedback.

I hope i can do my outstanding PDO work during the next few weeks so
the time frame is ok for me too.

However i'd like to see the 'ifsetor' or '?:' operator since it makes
many things much faster and easier to read.

Last but not least i have some forach-engine cleanup lingering around
which i will commit in the next days.

--
Best regards,
Marcus                            mailto:helly@php.net

Andi Gutmans

21 years ago

At 10:26 PM 2/2/2005 +0100, Marcus Boerger wrote:

>Hello Andi,
>
>Tuesday, February 1, 2005, 8:26:15 PM, you wrote:
>
> > Hey,
>
> > I just heard from Wez that PDO is in very advanced stages now (ready
> for beta).
> > I would like to start the PHP 5.1 release process. Due to the lack of
> > testing both the new engine VM and PDO have received I would like to start
> > with a beta process so that we get feedback.
>
>I hope i can do my outstanding PDO work during the next few weeks so
>the time frame is ok for me too.

Great.

>However i'd like to see the 'ifsetor' or '?:' operator since it makes
>many things much faster and easier to read.

I am not sure if the security filter functions aren't enough because they
will be used to gather and verify input which is the main purpose of ifsetor.
Also, we never found a great implementation but that's another story :)

>Last but not least i have some forach-engine cleanup lingering around
>which i will commit in the next days.

OK just don't break anything :)

Andi

Jason Garber

21 years ago

Hello Andi,

>>However i'd like to see the 'ifsetor' or '?:' operator since it makes
>>many things much faster and easier to read.

AG> I am not sure if the security filter functions aren't enough because they
AG> will be used to gather and verify input which is the main purpose of ifsetor.
AG> Also, we never found a great implementation but that's another story :)

ifsetor() has many uses other than input filtering although it is one
of the main uses.

ifsetor($var, default)  is the very clean, simple syntax that I think
should be used.  I do not believe that input filtering should be built
into ifsetor.

Thanks.

PS (The name, as long as it's fairly short, is not important to me at
all)

--
Best regards,
Jason                            mailto:jason@ionzoft.com

Sebastian Bergmann

21 years ago

Andi Gutmans wrote:

> Comments/Flames/Praises to this list :)

Just curious: Have you considered adding the operator overloading
patch [1] by Johannes Schlüter that has been floating around for a
while?

Greetings,
Sebastian

--
[1] http://anonsvn.schlueters.de/svn/phpatches/HEAD/operator_overloading.diff

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Derick Rethans

21 years ago

On Thu, 3 Feb 2005, Sebastian Bergmann wrote:

> Andi Gutmans wrote:
> > Comments/Flames/Praises to this list :)
>
>  Just curious: Have you considered adding the operator overloading
>  patch [1] by Johannes Schlüter that has been floating around for a
>  while?

This adds operator overloading to user classes?

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Sebastian Bergmann

21 years ago

Derick Rethans wrote:

> This adds operator overloading to user classes?

Yes, have a look at Johannes' Complex example [1].

--
[1] http://anonsvn.schlueters.de/svn/phpatches/HEAD/operator_overloading_example.php

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Derick Rethans

21 years ago

On Thu, 3 Feb 2005, Sebastian Bergmann wrote:

> Derick Rethans wrote:
> > This adds operator overloading to user classes?
>
>  Yes, have a look at Johannes' Complex example [1].

Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of people that they can add two
objects. Use C++/Java if you want this...

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Sebastian Bergmann

21 years ago

Derick Rethans wrote:

> Use C++/Java if you want this.

Java does not support operator overloading.

--
Sebastian Bergmann                      http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69

Derick Rethans

21 years ago

On Thu, 3 Feb 2005, Sebastian Bergmann wrote:

> Derick Rethans wrote:
> > Use C++/Java if you want this.
>
>  Java does not support operator overloading.

So, that means PHP shouldn't get it either, right? ;-)

Derick

Pierre-Alain Joye

21 years ago

On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
derick@php.net (Derick Rethans) wrote:

> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > Use C++/Java if you want this.
> >
> >  Java does not support operator overloading.
>
> So, that means PHP shouldn't get it either, right? ;-)

As I already asked in the past, I'm in favour to have them for
intern usage only (understand used by extension). As we already for
propoerties read or write. For those who do not know, you have no
way to know that you in a ++, -- call. At least for ++,-- and
friends.

A typical usage could be data that fits in a defined range (ie
date/time values).

Regards,

--Pierre

Terje Slettebø

21 years ago

> On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
> derick@php.net (Derick Rethans) wrote:
>
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> > > Derick Rethans wrote:
> > > > Use C++/Java if you want this.
> > >
> > >  Java does not support operator overloading.
> >
> > So, that means PHP shouldn't get it either, right? ;-)
>
> As I already asked in the past, I'm in favour to have them for
> intern usage only (understand used by extension).

Internal in what way? And why?

> As we already for
> propoerties read or write. For those who do not know, you have no
> way to know that you in a ++, -- call. At least for ++,-- and
> friends.

I'm not sure I understood the above, but if I understood it right, why would
that be?

class SomeClass
{
function operator++() // #1
{
return ++$this->value;
}

function operator($dummy) // #2 ***
{
return $value++;
}

var $value;
}

$object=new SomeClass();

++$object; // Calls #1
$object++; // Calls # 2

(***) This is how it's done in C++ (actually, a dummy int parameter), which
is a bit of a hack, to be able to specify both the pre- and
post-increment/decrement operators. #2 (and postfix "--") is the "odd" one,
since they are the only postfix operators among the operators.

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>(***) This is how it's done in C++ (actually, a dummy int parameter), which
TS>>is a bit of a hack, to be able to specify both the pre- and

In C++, functions differ by argument. In PHP, they don't.

Not to say I view that C++ hack as a kludge which is accepted only because
there's no other choice, more or less.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Pierre-Alain Joye

21 years ago

On Thu, 3 Feb 2005 18:12:44 +0100
tslettebo@broadpark.no (Terje Slettebø) wrote:

> > On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
> > derick@php.net (Derick Rethans) wrote:
> >
> > > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> > >
> > > > Derick Rethans wrote:
> > > > > Use C++/Java if you want this.
> > > >
> > > >  Java does not support operator overloading.
> > >
> > > So, that means PHP shouldn't get it either, right? ;-)
> >
> > As I already asked in the past, I'm in favour to have them for
> > intern usage only (understand used by extension).
>
> Internal in what way? And why?

Available for extensions only (means also not in user land), like
the get/set get_properties for objects.

> > As we already for
> > propoerties read or write. For those who do not know, you have
> > no way to know that you in a ++, -- call. At least for ++,-- and
> > friends.
>
> I'm not sure I understood the above, but if I understood it right,
> why would that be?

For now you cannot know if are in a '++' or a '--'. The operations
(I have to check that again :) are:

$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;

In my example (a date object, day being 31), at this I do not know
if one is assigning 32 to the property or if it's the result of
incrementation (or decrementation from 1 to 0).

Regards,

--Pierre

Christian Schneider

21 years ago

Derick Rethans wrote:

> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
>>Derick Rethans wrote:
>>>This adds operator overloading to user classes?
>> Yes, have a look at Johannes' Complex example [1].
>
> Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> practise. It confuses the hell out of people that they can add two
> objects. Use C++/Java if you want this...

I couldn't agree more. I like PHP not because it is the most compact or
flexible of all languages but because the syntax is quite simple.

Try explaining someone who just learned PHP and doesn't know your code
where to find the implementation of
$c = $a + $b;
as opposed to
$c= $a->add($b);
or
$c = Complex::add($a, $b);

Another little thought how confusion can easily happen with operator
overloading: $b = $a + 42; works but $b = 42 + $a; doesn't, i.e. the
overloaded addition isn't commutative.

Just my 2 Rappen,
- Chris

Terje Slettebø

21 years ago

> Derick Rethans wrote:
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> >>Derick Rethans wrote:
> >>>This adds operator overloading to user classes?
> >> Yes, have a look at Johannes' Complex example [1].
> >
> > Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> > practise. It confuses the hell out of people that they can add two
> > objects. Use C++/Java if you want this...
>
> I couldn't agree more. I like PHP not because it is the most compact or
> flexible of all languages but because the syntax is quite simple.
>
> Try explaining someone who just learned PHP and doesn't know your code
> where to find the implementation of
> $c = $a + $b;
> as opposed to
> $c= $a->add($b);
> or
> $c = Complex::add($a, $b);

If $a is an object of a class, then they would both be in the class
definition. One is called "add", and the other is called "operator+". What's
the problem with that?

> Another little thought how confusion can easily happen with operator
> overloading: $b = $a + 42; works but $b = 42 + $a; doesn't, i.e. the
> overloaded addition isn't commutative.

It would if operator overloading was allowed on free functions (as it is in
C++). E..g:

function operator+(complex $a, complex $b)
{
return new complex($a.real + $b.real, $a.imag + $b.imag);
}

The binary operators are recommended to to free functions, for this reason,
in C++.

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>If $a is an object of a class, then they would both be in the class
TS>>definition. One is called "add", and the other is called "operator+". What's
TS>>the problem with that?

The problem is that you can't really know what $a is - PHP is typeless.
You'll have to trace all the program up to $a's assignment and hope you
didn't miss reassignment on the way.

TS>>It would if operator overloading was allowed on free functions (as it is in
TS>>C++). E..g:

You can't do it like in C++, because in C++ function signature includes
argument types, and in PHP it does not. I.e., you can't write two
operators - one for complex+int and one for complex+complex. In general,
it's too much trouble for too little gain - except for select things like
complex and matrices (and maybe two more things like this) I don't see any
value in having, say, + overloaded. Using good old methods will never fail
you.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Terje Slettebø

21 years ago

> TS>>If $a is an object of a class, then they would both be in the class
> TS>>definition. One is called "add", and the other is called "operator+".

What's

> TS>>the problem with that?
>
> The problem is that you can't really know what $a is - PHP is typeless.

When you say "typeless", i think you mean "not statically typed". I've been
through this discussion elsewhere - a variable will at any one time have a
well-defined type (or unset), which you may overload on, so the language is
definitely not typeless. An example of a typeless (or single type language,
if you like) language is BCPL, where there was only one type, the machine
word.

As mentioned in another posting, operator overloading also exists in other
dynamically typed languages, such as Python and Perl.

> You'll have to trace all the program up to $a's assignment and hope you
> didn't miss reassignment on the way.

Yes, variables are dynamically typed, but when you call a function, you
typically have an idea of what its type is. Otherwise, the "type hints" for
PHP 5 would be pointless! By your argument.

> TS>>It would if operator overloading was allowed on free functions (as it

is in

> TS>>C++). E..g:
>
> You can't do it like in C++, because in C++ function signature includes
> argument types, and in PHP it does not.

That's right, so we'd really need function overloading to be able to use the
free function form, which I think is another good idea (function
overloading).

> I.e., you can't write two
> operators - one for complex+int and one for complex+complex. In general,
> it's too much trouble for too little gain

Well, you're certainly entitled to your opinion, but others, including me,
think it's worth it.

> - except for select things like
> complex and matrices (and maybe two more things like this) I don't see any
> value in having, say, + overloaded. Using good old methods will never fail
> you.

Neither will assembly code.

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>When you say "typeless", i think you mean "not statically typed". I've been

Not only, but in this case it is the main trait I meant.

TS>>through this discussion elsewhere - a variable will at any one time have a
TS>>well-defined type (or unset), which you may overload on, so the language is

That's the whole point - in PHP there's no mechanism you could overload
function based on the types of their parameters, neither statically nor
dynamically. To add this thing would be a very major change and will open
galactic-size can of worms (think "implicit conversions", "converting
constructors", "multiple inheritance", etc.). And this would seriously
complicate function call logic - which is very bad, because, unlike
statically-typed language, we can not offload this complexity to one-time
compile stage.

TS>>Yes, variables are dynamically typed, but when you call a function, you
TS>>typically have an idea of what its type is. Otherwise, the "type hints" for
TS>>PHP 5 would be pointless! By your argument.

Type hints check if the argument passed to function is of the right type.
They don't make PHP call different functions on different argument types.

TS>>That's right, so we'd really need function overloading to be able to use the
TS>>free function form, which I think is another good idea (function
TS>>overloading).

See above.

TS>>> - except for select things like
TS>>> complex and matrices (and maybe two more things like this) I don't see any
TS>>> value in having, say, + overloaded. Using good old methods will never fail
TS>>> you.
TS>>
TS>>Neither will assembly code.

What is with that assembly code that you keep mentioning it? Assembly code
is entirely irrelevant to the discussion, since, as I already explained
once, difference between assebmly code and higher-level programming
languages in in complexity incapsulation, while difference between
operator overloading and using method is purely syntactical - operator
overloading can be translated one-to-one to method calls without exposing
any complexity, while translating method call to assemly exposes a lot of
complexity.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Andi Gutmans

21 years ago

Guys,

This thread is cluttering the list.
This won't be implemented, we discussed it in the past and already reached
that decision, pretty much all of the PHP dev team agree so I suggest to
drop it and let's focus on stuff which will go into PHP...
Sorry to be so abrupt but this thread is getting too long, too many
theoretical arguments when clearly this won't happen.

Andi

Wez Furlong

21 years ago

+1.

Nothing to see here, move along.

On Thu, 03 Feb 2005 18:01:37 -0800, Andi Gutmans <andi@zend.com> wrote:

Terje Slettebø

21 years ago

> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > This adds operator overloading to user classes?
> >
> >  Yes, have a look at Johannes' Complex example [1].
>
> Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> practise. It confuses the hell out of people that they can add two
> objects.

That's only confusing if you don't know that operator overloading is
possible. In C++, it's perfectly natural to be able to e.g. add values of
user-defined types. It also enables generic code, such as:

function some_calculation($num1, $num2)
{
$num1+=1;
$num2+=num1;
...
}

This would then work for any object (built-in type or user-defined type
(class)) having operator+= defined.

Why this would be confusing is beyond me... Could you enlighten me?

Specifically, do you find the following:

$result=$c1.multiply($c2).divide($c1.add($c2));

less "confusing" than:

$result=($c1 * $c2) / ($c1 + $c2);

?

>Use C++/Java if you want this...

Why would it be ok there, but not in PHP? It also exists in other scripting
languages, such as Python and Perl.

BTW, as another poster pointed out, it doesn't exist in Java, either, except
for the "+" exception for strings. I think omitting that is a case of
"throwing the baby out with the bath water". Yes, used incorrectly, operator
overloading can be confusing, but that's also the case for more or less any
language feature, and we don't ban them. It's no less confusing having the
member function "add()" perform subtraction, as it is to let the "+" do
that.

Regards,

Terje

Jani Taskinen

21 years ago

On Thu, 3 Feb 2005, Terje Slettebø wrote:

> Why would it be ok there, but not in PHP? It also exists in other scripting
> languages, such as Python and Perl.

PHP is not Perl or Python or <add-your-favorite-language-here>.

--Jani

Stanislav Malyshev

21 years ago

JT>>> Why would it be ok there, but not in PHP? It also exists in other
JT>>scripting > languages, such as Python and Perl.

BTW, I don't remember anything useful done with operator overloading on
Perl. I must say I wrote a lot of Perl when nothing like Perl 6 existed,
so I may be somewhat behind, but still I find it hard to imagine why Perl
(at least if we speak of Perl 4/5) would need one.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Terje Slettebø

21 years ago

>From: "Jani Taskinen" <sniper@iki.fi>

> On Thu, 3 Feb 2005, Terje Slettebø wrote:
>
> > Why would it be ok there, but not in PHP? It also exists in other

scripting

> > languages, such as Python and Perl.
>
>      PHP is not Perl or Python or <add-your-favorite-language-here>.

That's not an argument against operator overloading. The question is why
would it not be appropriate for PHP? Dynamic typing has been mentioned, and
when I said that it exists in other dynamically typed languages, as well, I
get the reply that "PHP is not language xxx". What kind of reply is that?!
Ilia Alshanetsky suggested in a posting that the PHP community in general
might not be ready for its safe introduction (i.e. they would typically
misuse it). I hope it's not the case; after all, it's not such an "advanced"
feature, when several mainstream languages has it.

Regards,

Terje

David Zülke

21 years ago

No offense, but before even thinking about operator overloading support,
really useful and crucial stuff like namespaces or Unicode support should be
tackled first.

David

Jani Taskinen

21 years ago

Yeah, and don't forget goto, <?php=, removing magic_quotes_* and
register_globals, making the language completely case-sensitive,
etc, etc.

Just guess if any of that list will happen..ever? :)

--Jani


On Thu, 3 Feb 2005, David Zülke wrote:

Jani Taskinen

21 years ago

On Thu, 3 Feb 2005, Terje Slettebø wrote:

>> From: "Jani Taskinen" <sniper@iki.fi>
>
>> On Thu, 3 Feb 2005, Terje Slettebø wrote:
>>
>>> Why would it be ok there, but not in PHP? It also exists in other
> scripting
>>> languages, such as Python and Perl.
>>
>>      PHP is not Perl or Python or <add-your-favorite-language-here>.
>
> That's not an argument against operator overloading. The question is why
> would it not be appropriate for PHP? Dynamic typing has been mentioned, and
> when I said that it exists in other dynamically typed languages, as well, I
> get the reply that "PHP is not language xxx". What kind of reply is that?!

Quote from your mail:

"Why would it be ok there, but not in PHP? It also exists in other scripting
languages, such as Python and Perl."

Please explain me why it's okay for you to use the other-languages-card
but not for me? :)

Please, end this thread already and face the fact that this feature
will not get into PHP 5.1.

--Jani

Terje Slettebø

21 years ago

>From: "Jani Taskinen" <sniper@iki.fi>

> On Thu, 3 Feb 2005, Terje Slettebø wrote:
>
> >> From: "Jani Taskinen" <sniper@iki.fi>
> >
> >> On Thu, 3 Feb 2005, Terje Slettebø wrote:
> >>
> >>> Why would it be ok there, but not in PHP? It also exists in other
> > scripting
> >>> languages, such as Python and Perl.
> >>
> >>      PHP is not Perl or Python or <add-your-favorite-language-here>.
> >
> > That's not an argument against operator overloading. The question is why
> > would it not be appropriate for PHP? Dynamic typing has been mentioned,

and

> > when I said that it exists in other dynamically typed languages, as

well, I

> > get the reply that "PHP is not language xxx". What kind of reply is

that?!

>
>      Quote from your mail:
>
>      "Why would it be ok there, but not in PHP? It also exists in other

scripting

>      languages, such as Python and Perl."
>
>      Please explain me why it's okay for you to use the

other-languages-card

>      but not for me? :)

Ok. The argument went something like this: I asked (although that was
originally in another thread) about the possibility of getting operator
overloading in PHP, and I presented reasons for why this may be useful. Then
someone replied that PHP is dynamically typed, so it "doesn't fit the
language". I countered with that there are other languages that are also
dynamically typed, but where they do have operator overloading. Now, if the
"doesn't fit the language" argument should stick, one could need to either:

1) Explain why it's a bad idea in these other languages, as well, or:
2) Explain how PHP is different, and why it doesn't fit PHP, unlike these
languages.

Now, have I got any answers to this? No! All I've got (from your posting,
anyway) is "PHP is not language xxx". And? How does it change the argument?
In what way is it different, so that operator overloading would not fit with
PHP? I've got some answers in this thread, and I'll also search the archive
for the rest, but "PHP is not language xxx" is a meaningless "answer".

My use of the other languages was to show that other languages find it
useful. Your use of other languages... well, it only says that PHP are not
them, which doesn't really say anything beyond the obvious. I'm sorry, but
our two arguments can't be compared.

>      Please, end this thread already and face the fact that this feature
>      will not get into PHP 5.1.

I have no illusions of it going into PHP 5.1... This wouldn't be appropriate
for a point release, for one thing.

I have also very little belief of it ever getting into PHP, judging from the
discussion.

Regards,

Terje

Andi Gutmans

21 years ago

At 11:23 AM 2/3/2005 +0100, Derick Rethans wrote:

>On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > This adds operator overloading to user classes?
> >
> >  Yes, have a look at Johannes' Complex example [1].
>
>Okay, mega Yuck then. Although it looks cool, I consider it as a bad
>practise. It confuses the hell out of people that they can add two
>objects. Use C++/Java if you want this...

BTW, in general Java also decided that it sucks. Except for + which is a
bit magical it also requires to use verbose methods. This is a big
time/life saver because operator overloading is very confusing and obscure.
I think it's only nice in theory and not in real world usage.

Andi

Stanislav Malyshev

21 years ago

SB>> patch [1] by Johannes Schl?ter that has been floating around for a
SB>> while?

1. I personally don't think operator overloading is a good idea. It
doesn't add you anything you couldn't do without it the same way - it's
pure syntax sugar. And it really ruins the readability of the code - go
figure what $i++ means now, in absence of any type delcarations.

2. The referenced patch raises doubts - why it allows to override / but
not %, for example? What with all other operators? Why add would work as
$foo + 1, but 1 + $foo won't? Will + be non-commutative operation from now
on? What with assign-ops - it would leak memory in this case?

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Pierre-Alain Joye

21 years ago

On Thu, 3 Feb 2005 13:00:13 +0200 (IST)
stas@zend.com (Stanislav Malyshev) wrote:

> SB>> patch [1] by Johannes Schl?ter that has been floating around
> SB>for a> while?
>
> 1. I personally don't think operator overloading is a good idea.
> It doesn't add you anything you couldn't do without it the same
> way - it's pure syntax sugar. And it really ruins the readability
> of the code - go figure what $i++ means now, in absence of any
> type delcarations.

(speaking only for internal needs)

I think you are wrong here. Example:
d = new date(2005,2,31);
d->day++:

You are out, no way to know where you are inside the read or write
property(ies) functions.

That said I agree that userland operators overloading is not a good
idea.

Regards,

--Pierre

Johannes Schlueter

21 years ago

Hi,

Not wanting to discuss the pros and cons of operator overloading in PHP a
few notes about the implementation:

Stanislav Malyshev wrote:

> 2. The referenced patch raises doubts - why it allows to override / but
> not %, for example? What with all other operators? Why add would work as

I've written the patch mainly for learning about PHP and the Zend Engine as
a proof-of-concept and not as a thing I would like to propose so I was
satisfied when it was running. By showing it to a few people I got some
feedback about the way I've implemented it and learned how to do it better.
Most of this input ended at my brain not in the patch so it's far from
good, I still stress that I'm no C coder ;-)
So all what's (not) there needs to be seen from that position. For being
committed it would need some work.

> $foo + 1, but 1 + $foo won't? Will + be non-commutative operation from now

In case of operator overloading this would become true - not for simple
types - when leaving the field of simple numbers an "addition operation"
isn't allways communitative. Think on "adding" two strings - you would
expect different results from "foo"+"bar" and "bar"+"foo". (Yes, I know
that PHP has the concat operator . so this is just an example)

> on? What with assign-ops - it would leak memory in this case?

As said it's in proof-of-concept state. I last looked over it during the
conference in Frankfurt and afair at least --enable-debug didn't report a
leak ;-)

Enough (if not even too much) for the moment,
johannes

Terje Slettebø

21 years ago

> SB>> patch [1] by Johannes Schl?ter that has been floating around for a
> SB>> while?
>
> 1. I personally don't think operator overloading is a good idea. It
> doesn't add you anything you couldn't do without it the same way - it's
> pure syntax sugar.

As someone said, "Syntactic sugar matters, or we'd all be writing assembly
code." :)

Besides, it's not "just" syntactic sugar: See my other posts in this thread,
but briefly, they enable "generic code" - code that may be used by both
built-in and user-defined types, without knowing or caring which is which.
That is indeed powerful, and most of the advances in later years in C++ has
come in the area of generic programming (where templates are used for this,
since types are checked at compile-time).

> And it really ruins the readability of the code - go
> figure what $i++ means now, in absence of any type delcarations.

If it's sensibly implemented, it should increment $i (whatever that is), and
return the previous value.

This is no more confusing than "increment_and_return($i)", where you may
also need to look at the function definition. I find the first version much
clearer, though.

> 2. The referenced patch raises doubts - why it allows to override / but
> not %, for example? What with all other operators?

I agree that if operator overloading was added, it should be available for
all operators where it makes sense.

> Why add would work as
> $foo + 1, but 1 + $foo won't?

Both would work if we allow operator overloading on free functions. But that
may be too radical for some people, it seems. Just to drive the point home:
Operator (and function) overloading is not an OO feature. However, it's
often found in OO languages, and complements OO well. It's a different kind
of polymorphism.

> Will + be non-commutative operation from now on?

There shoudn't be a need for that. We should try to avoid such surprises.

> What with assign-ops - it would leak memory in this case?

Why would it do that?

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>As someone said, "Syntactic sugar matters, or we'd all be writing assembly
TS>>code." :)

Someone was wrong. There are syntax constructs that allow to reduce
complexity of the code, and there are constructs that make the code have
the same complexity but look prettier to the eyes of the writer. The
latter is syntax sugar. It is important, but not at the price of making
code harder to read or language slower to work.

TS>>Besides, it's not "just" syntactic sugar: See my other posts in this thread,
TS>>but briefly, they enable "generic code" - code that may be used by both
TS>>built-in and user-defined types, without knowing or caring which is which.

I don't see how using $a + 1 is better than using $a->add(1) in this
regard.

TS>>That is indeed powerful, and most of the advances in later years in C++ has
TS>>come in the area of generic programming (where templates are used for this,
TS>>since types are checked at compile-time).

C++ is typed, so you need to jump trhough various hoops to make it work in
non-typed way, while preserving it's typedness benefits. PHP works
differently - you don't have benefits and need no hoops.

TS>>This is no more confusing than "increment_and_return($i)", where you may
TS>>also need to look at the function definition. I find the first version much
TS>>clearer, though.

Well, I guess it's the matter of personal taste. For me, the second is
the clear winner - you can name function after what it actually does and
not hope that everybody knows ++ makes an iterator go to the next element.

TS>>Both would work if we allow operator overloading on free functions. But that

It can't be done without making PHP strict-typed - you coldn't really
distinguish which function is to be called, and you couldn't distinguish
between functions with same name. Even if you could - how many operator+'s
you are willing to write? For all type combinations? Or what is supposed
to happen if + called for type combination that you don't have an operator
for?

TS>>Operator (and function) overloading is not an OO feature. However, it's
TS>>often found in OO languages, and complements OO well. It's a different kind
TS>>of polymorphism.

It's no kind of polymorphism at all. It just an infix form of writing a
method instead of prefix form, with additional problem that it is confused
with plain old arithmetics. I see no value at all in this except for "cool
toy" value - which is not enough to add such a serious change in the
language.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Terje Slettebø

21 years ago

> TS>>As someone said, "Syntactic sugar matters, or we'd all be writing

assembly

> TS>>code." :)
>
> Someone was wrong. There are syntax constructs that allow to reduce
> complexity of the code, and there are constructs that make the code have
> the same complexity but look prettier to the eyes of the writer.

It depends on how you define "complexity". Are the following two lines
equally complex to you:

1) $result=$c1.multiply($c2).divide($c1.add($c2));

2) $result=($c1 * $c2) / ($c1 + $c2);

They sure aren't to me. Moreover, they are not the same: operator
overloading enable you to use infix notation, whereas functions use prefix,
only.

> The
> latter is syntax sugar. It is important, but not at the price of making
> code harder to read

If it makes the code harder to read, it's not much of "syntactic sugar", is
it? I can't see why operator overloading should make it harder to read. The
only thing I can think of is that, given that there's no type declarations
in PHP, it may be hard to know, looking at a line, what the type of the
variable is. However, in a properly written program, the actual type may not
be that important. Take for example:

$sum = $money1 + $money2;

Whether or not the variables are built-ins or from a money/currency class,
should matter little to your understanding of this code.

> or language slower to work.

Why would it become slower. As you say, the notation is essentially
"syntactic sugar" for a function call, and should be equally fast.

> TS>>Besides, it's not "just" syntactic sugar: See my other posts in this

thread,

> TS>>but briefly, they enable "generic code" - code that may be used by

both

> TS>>built-in and user-defined types, without knowing or caring which is

which.

>
> I don't see how using $a + 1 is better than using $a->add(1) in this
> regard.

What if you want to add two variables?

> TS>>That is indeed powerful, and most of the advances in later years in

C++ has

> TS>>come in the area of generic programming (where templates are used for

this,

> TS>>since types are checked at compile-time).
>
> C++ is typed

Statically typed, yes.

>, so you need to jump trhough various hoops to make it work in
> non-typed way, while preserving it's typedness benefits.

Yes, if you want to use C++ in a typeless/dynamically typed way, you need to
use things like templates, or a variant type. However, since those are
available, you get the benefits of something similar to type inference, and
also static type checking.

> PHP works differently - you don't have benefits and need no hoops.

You don't have benefits of what? (Should "don't" have been omitted?)

> TS>>This is no more confusing than "increment_and_return($i)", where you

may

> TS>>also need to look at the function definition. I find the first version

much

> TS>>clearer, though.
>
> Well, I guess it's the matter of personal taste. For me, the second is
> the clear winner - you can name function after what it actually does and
> not hope that everybody knows ++ makes an iterator go to the next element.

Oh, well. Programming by guesswork is always hard. A point with programming
languages is that once you've learned them, and their abstractions, it makes
it easier for you to program. Operator overloading is no different.

> TS>>Both would work if we allow operator overloading on free functions.

But that

>
> It can't be done without making PHP strict-typed - you coldn't really
> distinguish which function is to be called, and you couldn't distinguish
> between functions with same name.

Yes, you'd need function overloading (we already have type hints, which
could be used for the overload resolution).

> Even if you could - how many operator+'s
> you are willing to write? For all type combinations?

That depends on what you want. I can't see how this question is different
from "How many member functions (like add()) are you willing to write?"?

> Or what is supposed
> to happen if + called for type combination that you don't have an operator
> for?

An error, like today.

> TS>>Operator (and function) overloading is not an OO feature. However,

it's

> TS>>often found in OO languages, and complements OO well. It's a different

kind

> TS>>of polymorphism.
>
> It's no kind of polymorphism at all.

Yes, overloading is a form of polymorphism. Depending on the type of the
arguments, different functions are called. This is analogous to
inheritance-based polymorphism (virtual functions). See
http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf for a
good treatment of the various kinds of polymorphisms there are (even if the
article is rather mathematical/technical).

> It just an infix form of writing a
> method instead of prefix form, with additional problem that it is confused
> with plain old arithmetics. I see no value at all in this except for "cool
> toy" value - which is not enough to add such a serious change in the
> language.

I beg to differ. Operator overloading allows you to write what essentially
are domain-specific languages (DSLs) in the language itself. For example
Boost.Spirit allows you to write a parser, by expressing the rules in
near-EBNF form, directly in the code!
(http://www.boost.org/libs/spirit/doc/introduction.html) Do _that_ in PHP.

Regards,

Terje

Derick Rethans

21 years ago

On Thu, 3 Feb 2005, [iso-8859-1] Terje Slettebø wrote:

> > TS>>As someone said, "Syntactic sugar matters, or we'd all be
> > TS>>writing assembly code." :)
> >
> > Someone was wrong. There are syntax constructs that allow to reduce
> > complexity of the code, and there are constructs that make the code have
> > the same complexity but look prettier to the eyes of the writer.
>
> It depends on how you define "complexity". Are the following two lines
> equally complex to you:

Let me be blunt as you;'e not giving up. We will not add it. Period,
punt, punktum. This discussion is pointless - stop it!

Derick

--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org

Terje Slettebø

21 years ago

>From: "Derick Rethans" <derick@php.net>

>> > TS>>As someone said, "Syntactic sugar matters, or we'd all be
>> > TS>>writing assembly code." :)
>> >
>> > Someone was wrong. There are syntax constructs that allow to reduce
>> > complexity of the code, and there are constructs that make the code

have

>> > the same complexity but look prettier to the eyes of the writer.
>>
>> It depends on how you define "complexity". Are the following two lines
>> equally complex to you:

>Let me be blunt as you;'e not giving up. We will not add it. Period,
>punt, punktum. This discussion is pointless - stop it!

Apparently it is, but not because I've got convincing arguments in return.

Regards,

Terje

Greg Beaver

21 years ago

Terje Slettebø wrote:

> 1) $result=$c1.multiply($c2).divide($c1.add($c2));
>
> 2) $result=($c1 * $c2) / ($c1 + $c2);
>
> They sure aren't to me. Moreover, they are not the same: operator
> overloading enable you to use infix notation, whereas functions use prefix,
> only.

Um, you're wrong.  Infix is quite easy to do using (static or
non-static) functions:

3) $result = Complex::divide(Complex::multiply($c1, $c2),
Complex::add($c1, $c2));

Greg

Terje Slettebø

21 years ago

>From: "Greg Beaver" <cellog@php.net>

> Terje Slettebø wrote:
> > 1) $result=$c1.multiply($c2).divide($c1.add($c2));
> >
> > 2) $result=($c1 * $c2) / ($c1 + $c2);
> >
> > They sure aren't to me. Moreover, they are not the same: operator
> > overloading enable you to use infix notation, whereas functions use

prefix,

> > only.
>
> Um, you're wrong.  Infix is quite easy to do using (static or
> non-static) functions:
>
> 3) $result = Complex::divide(Complex::multiply($c1, $c2),

Complex::add($c1, $c2));

Let me rewrite your expression as an abstract expression:

result = op(op(c1, c2), op(c1, c2))

Here, "op" is the function name ("add", etc.). As you can see, your
expression is still one using prefix operators ("op arg1 arg2"), rather than
infix ("arg1 op arg2"). I'm afraid your correction is incorrect.

Your example is the same as 1), above, using static functions.

Regards,

Terje

Ilia A.

21 years ago

C++ is not PHP and the sooner you realize this the better it will be.
Adding operator overloading will add yet another layer of "magic" that
will confuse users, who for the most part have demonstrated that they
are not ready for such features. If anything it'll only over complicate
applications making them neigh impossible to debug and require all sorts
of hackery inside the language itself to support this functionality.

Ilia

Terje Slettebø wrote:

Terje Slettebø

21 years ago

> From: "Jani Taskinen" <sniper@iki.fi>
>
> C++ is not PHP and the sooner you realize this the better it will be.

I do realise it. However, I don't accept that as an argument against things
like operator overloading, which is found in scripting languages comparable
to PHP.

> Adding operator overloading will add yet another layer of "magic" that
> will confuse users, who for the most part have demonstrated that they
> are not ready for such features.

Judging from much of the PHP code I've seen, I'm sorry to say that you may
be right... However, that doesn't mean _no_ users are ready for it.

> If anything it'll only over complicate
> applications making them neigh impossible to debug and require all sorts
> of hackery inside the language itself to support this functionality.

My experience isn't that misuse of language features is the biggest cause of
messy code, as inexperienced developers typically aren't aware of more
"advanced" features, and therefore don't use them. Rather, my experience is
that the biggest cause of messy code is simply lack of competence, beyond
knowing the language itself. Learning to be a good programmer takes many
years, regardless of language.

Those who are experienced enough to "shoot themselves in the foot", but not
experienced enough to aim properly, :) might, however, obfuscate code with
"misuse" of more "advanced" language constructs (variable variables and
variable functions comes to mind), but that doesn't mean we should forbid
these features in the language!

Used properly, if anything, the features proposed in my postings (like
overloading, and optional type checking) would allow people to _simplify_
their code. C++ code is typically simpler than Java code, for this reason.
Take this example (incrementing an element in a map):

C++:

++my_map[key];

Java:

if ( !my_map.containsKey( key ) )
my_map.put( key, new Integer( 1 ) );
else
{
Integer count = ( Integer )my_map.get( key ) );
int icount = count.IntValue();
my_map.put( key, new Integer( ++icount ) );
}

Operator overloading isn't the only thing playing a part, here (the ability
to treat built-in and user-defined types the same way is another major
factor), but it's a major factor.

Now, for this particular example, PHP actually has a similarly succinct
form, but that's only because the PHP array _is_ a map, so you have a
built-in type with operators:

++$my_map[$key];

The advantage of operator overloading is similar to the advantage of
symbolic notation in mathematics: It allows you to succinctly express your
intent, and it's also international.

Regards,

Terje

Christian Schneider

21 years ago

Terje Slettebø wrote:

> Those who are experienced enough to "shoot themselves in the foot", but not
> experienced enough to aim properly, :) might, however, obfuscate code with
> "misuse" of more "advanced" language constructs (variable variables and
> variable functions comes to mind), but that doesn't mean we should forbid
> these features in the language!

You're wrong, that's exactly one of the things PHP does: Keep the
language simple by limiting the amount of (syntactic) magic.

> their code. C++ code is typically simpler than Java code, for this reason.

Can we please stop comparing PHP to C++? They have completely different
design philosophies (and so have Python, Perl and Ruby).

> symbolic notation in mathematics: It allows you to succinctly express your
> intent, and it's also international.

PHP is _not_ about expressing things succinctly but comprehensibly, i.e.
with simple language constructs like method calls.

Regards,
- Chris

Terje Slettebø

21 years ago

>From: "Christian Schneider" <cschneid@cschneid.com>

> Terje Slettebø wrote:
> > Those who are experienced enough to "shoot themselves in the foot", but

not

> > experienced enough to aim properly, :) might, however, obfuscate code

with

> > "misuse" of more "advanced" language constructs (variable variables and
> > variable functions comes to mind), but that doesn't mean we should

forbid

> > these features in the language!
>
> You're wrong

We should forbid variable variables and variable functions? That's what I
talked about when we said "that doesn't mean we should forbid these features
in the language".

>, that's exactly one of the things PHP does: Keep the
> language simple by limiting the amount of (syntactic) magic.

Keeping a language simple is not necessary a good thing in itself. C is an
example of a relatively simple language, for example. When we make
applications, there's a certain amount of "essential complexity", and that
complexity has to go somewhere. When we have OO support, and libraries, we
can delegate much of that complexity to the language/library, making our
programs simpler. If the complexity is not in the language or library, it'll
be in the programs. I'd rather have the complexity in the language or
library, so that the programs can be simpler.

Regards,

Terje

Stig S. Bakken

21 years ago

On Thu, 3 Feb 2005, Sebastian Bergmann wrote:

> Andi Gutmans wrote:
> > Comments/Flames/Praises to this list :)
>
>  Just curious: Have you considered adding the operator overloading
>  patch [1] by Johannes Schlüter that has been floating around for a
>  while?

Operator overloading in PHP?  Over my smoking carcass!

PHP 5 returns object handles, which lets you do _exactly_ the same thing,
only without the obscurity.

Nobody needs overloaded operators.  Code should be readable, not
cuddly-cute.

- Stig

Terje Slettebø

21 years ago

> From: "Stig S. Bakken" <stig@yahoo-inc.com>
>
> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Andi Gutmans wrote:
> > > Comments/Flames/Praises to this list :)
> >
> >  Just curious: Have you considered adding the operator overloading
> >  patch [1] by Johannes Schlüter that has been floating around for a
> >  while?
>
> Operator overloading in PHP?  Over my smoking carcass!
>
> PHP 5 returns object handles, which lets you do _exactly_ the same thing,
> only without the obscurity.

You mean $a + $b? add($a, $b) is _not_ "exactly the same thing".

> Nobody needs overloaded operators.  Code should be readable, not
> cuddly-cute.

Hm, I'm surprised by this response from someone who's name I recognise as an
active PHP contributor. The answer strikes me as either arrogant and/or
ignorant (note: I'm not saying you are that, but that's how the reply comes
across, given what what operator overloading is about). As I've pointed out
in other postings in this thread, operator overloading is about much more
than "just" "syntactic sugar". In C++, for example, it enables important
things such as function objects (being able to pass an object to a function,
for example, and have it behave as a function, enabling functional
programming, as well). This is not possible (possibly without jumping
through major hoops) in PHP.

However, I see from this and other threads, that there's not much chance of
evolution of PHP to support more "advanced" features (which are common in
other scripting languages, as mentioned). It seems basic OO support is about
the only thing the PHP community can handle when it comes to expressiveness
in the language. Oh, well.

Oh, and the comment about "Code should be readable, not cuddly-cute":
Operator overloading is about being able to express your intent clearer in
the code - leading to _more_ readable code than the corresponding function
alternative (see my arithmetic example in another posting). It has nothing
to do with cuteness, and everything to do with being to express your intent
clearly in the code. But it seems the community isn't ready for this. Too
bad. Maybe in PHP 10.

Regards,

Terje

George Schlossnagle

21 years ago

On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote:

> Hm, I'm surprised by this response from someone who's name I recognise
> as an
> active PHP contributor. The answer strikes me as either arrogant and/or
> ignorant (note: I'm not saying you are that, but that's how the reply
> comes
> across, given what what operator overloading is about). As I've
> pointed out
> in other postings in this thread, operator overloading is about much
> more
> than "just" "syntactic sugar". In C++, for example, it enables
> important
> things such as function objects (being able to pass an object to a
> function,
> for example, and have it behave as a function, enabling functional
> programming, as well). This is not possible (possibly without jumping
> through major hoops) in PHP.

That's because functions are not first-class objects in PHP.  You can
do this same thing in straight C without operator overloading.  While
I'm happy (for you) that you like operator overloading, the view that
it is inherently evil and leads to obtuse, magical code is not
relegated to us PHP luddites.  These ideas have all been discussed in
depth long before you appeared on the scene to decry our lack of
interest in 'evolving' the language to your liking.

George

Terje Slettebø

21 years ago

>From: "George Schlossnagle" <george@omniti.com>

By the way, I have your book ("Advanced PHP Programming"), which I found
very good. :) I've also recently got Andi Gutmans, Stig S. Bakken and Derick
Rethans book, "PHP 5 Power Programming", which, from what I've seen of it,
also looks very good, and I'm looking forward to reading it.

>On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote:
>> Hm, I'm surprised by this response from someone who's name I recognise
>> as an
>> active PHP contributor. The answer strikes me as either arrogant and/or
>> ignorant (note: I'm not saying you are that, but that's how the reply
>> comes
>> across, given what what operator overloading is about). As I've
>> pointed out
>> in other postings in this thread, operator overloading is about much
>> more
>> than "just" "syntactic sugar". In C++, for example, it enables
>> important
>> things such as function objects (being able to pass an object to a
>> function,
>> for example, and have it behave as a function, enabling functional
>> programming, as well). This is not possible (possibly without jumping
>> through major hoops) in PHP.

>That's because functions are not first-class objects in PHP.  You can
>do this same thing in straight C without operator overloading.  While
>I'm happy (for you) that you like operator overloading, the view that
>it is inherently evil and leads to obtuse, magical code is not
>relegated to us PHP luddites.  These ideas have all been discussed in
>depth long before you appeared on the scene to decry our lack of
>interest in 'evolving' the language to your liking.

Yes, I know that operator overloading, as well as statically
typed/dynamically typed, type checking, etc. are hotly debated topics, and
that can be healthy, at least as long as there are reasonable arguments for
either side. What I decried wasn't this thing in particular, and I'm
relatively new to the PHP online community, but from the responses I got,
felt something of a complacency ("The language is good enough as it is. Who
needs advanced features. They may be misused. Etc."), and I guess I reacted
to that, because I find it rather different in the C++ mailing lists and
newsgroups, where there's often lively discussions about the evolution of
the language. So it was more a perceived lack of willingness to consider, or
reconsider, proposals, and give reasonable arguments in return. Arguments
where given, I replied to them, and then it typically went nowhere from
there. Anyway, I'd be interested in any evolution, and by all means, PHP 5
has come a long way. But it probably wouldn't have been like this, had there
not been "early adopters", and people pushing for things like better OO
support.

Let me also mentioned that I _have_ found cool things in PHP, especially
things making it easier for web-programming, such as things like variable
functions, where you may dispatch to a function based on a string, for
example a GET parameter. This can lead to rather elegant code. Likewise, the
OO support is quite good, now.

Regards,

Terje

George Schlossnagle

21 years ago

On Feb 3, 2005, at 5:51 PM, Terje Slettebø wrote:

>> From: "George Schlossnagle" <george@omniti.com>
>
> By the way, I have your book ("Advanced PHP Programming"), which I
> found
> very good. :) I've also recently got Andi Gutmans, Stig S. Bakken and
> Derick
> Rethans book, "PHP 5 Power Programming", which, from what I've seen of
> it,
> also looks very good, and I'm looking forward to reading it.

Thanks.  I've heard good things about Andi, Stig and Derick's book as
well.

>
>> On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote:
>>> Hm, I'm surprised by this response from someone who's name I
>>> recognise
>>> as an
>>> active PHP contributor. The answer strikes me as either arrogant
>>> and/or
>>> ignorant (note: I'm not saying you are that, but that's how the reply
>>> comes
>>> across, given what what operator overloading is about). As I've
>>> pointed out
>>> in other postings in this thread, operator overloading is about much
>>> more
>>> than "just" "syntactic sugar". In C++, for example, it enables
>>> important
>>> things such as function objects (being able to pass an object to a
>>> function,
>>> for example, and have it behave as a function, enabling functional
>>> programming, as well). This is not possible (possibly without jumping
>>> through major hoops) in PHP.
>
>> That's because functions are not first-class objects in PHP.  You can
>> do this same thing in straight C without operator overloading.  While
>> I'm happy (for you) that you like operator overloading, the view that
>> it is inherently evil and leads to obtuse, magical code is not
>> relegated to us PHP luddites.  These ideas have all been discussed in
>> depth long before you appeared on the scene to decry our lack of
>> interest in 'evolving' the language to your liking.
>
> Yes, I know that operator overloading, as well as statically
> typed/dynamically typed, type checking, etc. are hotly debated topics,
> and
> that can be healthy, at least as long as there are reasonable
> arguments for
> either side. What I decried wasn't this thing in particular, and I'm
> relatively new to the PHP online community, but from the responses I
> got,
> felt something of a complacency ("The language is good enough as it
> is. Who
> needs advanced features. They may be misused. Etc."), and I guess I
> reacted
> to that, because I find it rather different in the C++ mailing lists
> and
> newsgroups, where there's often lively discussions about the evolution
> of
> the language.

The real problem is that there's a constant influx of (usually)
well-meaning people like yourself who come to the lists to propose
ideas which have been discussed in depth numerous times before and
which have been discarded (for better or worse, my personal opinion is
for better in this case).  'Prone to misuse' and 'tends to result in
unmaintainable code' are (in my exposure) two pretty common reasons
that people dislike operator overloading.

At any rate, it's been discussed before and shelved, long before you
came on the scene.  Even though the topic is new for you in this venue,
it's old for many other people, and it gets annoying to rehash the same
topics every couple months when someone new joins the list.  The
discussions are all in the archives though, if you want to see the
less-reactionary roots of the rejections.

George

Terje Slettebø

21 years ago

>From: "George Schlossnagle" <george@omniti.com>

>> Yes, I know that operator overloading, as well as statically
>> typed/dynamically typed, type checking, etc. are hotly debated topics,
>> and
>> that can be healthy, at least as long as there are reasonable
>> arguments for
>> either side. What I decried wasn't this thing in particular, and I'm
>> relatively new to the PHP online community, but from the responses I
>> got,
>> felt something of a complacency ("The language is good enough as it
>> is. Who
>> needs advanced features. They may be misused. Etc."), and I guess I
>> reacted
>> to that, because I find it rather different in the C++ mailing lists
>> and
>> newsgroups, where there's often lively discussions about the evolution
>> of the language.

>The real problem is that there's a constant influx of (usually)
>well-meaning people like yourself who come to the lists to propose
>ideas which have been discussed in depth numerous times before and
>which have been discarded (for better or worse, my personal opinion is
>for better in this case).

I figured that could be the case, which is also, in my first postings, I
said that if this had been discussed before, I'd appreciate pointers to it,
because I hadn't found it in the archive. However, I got hardly any response
to that, which is why I kept asking about things that may have been asked
and answered a zillion times.

>At any rate, it's been discussed before and shelved, long before you
>came on the scene.  Even though the topic is new for you in this venue,
>it's old for many other people, and it gets annoying to rehash the same
>topics every couple months when someone new joins the list.  The
>discussions are all in the archives though, if you want to see the
>less-reactionary roots of the rejections.

I've searched for "overloading" on the archive for this list, as well as
others and the newsgroups, but, as I said above, found very little about it.
However, now that I know it's there, I'll make a new attempt.

Thanks for your reply.

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>across, given what what operator overloading is about). As I've pointed out
TS>>in other postings in this thread, operator overloading is about much more
TS>>than "just" "syntactic sugar". In C++, for example, it enables important

I think you did not succeed in proving this point. You keep bringing
examples of how useful it is in C++ - which can be interesting to debate,
but is entirely irrelevant to PHP, since PHP is different from C++ on many
levels and tasks that are solved with operators in C++ often even not
exist in PHP (like "smart pointers", etc.). I still fail to see how it can
be really useful - in terms of making something that was very hard to do
before easy to do now - beyond they syntax sugar value.

TS>>things such as function objects (being able to pass an object to a function,
TS>>for example, and have it behave as a function, enabling functional
TS>>programming, as well). This is not possible (possibly without jumping
TS>>through major hoops) in PHP.

Surely it is. Via __call, for example, which is no worse than operator().
Yes, you could not write it the same syntax as C++ - so what?

TS>>However, I see from this and other threads, that there's not much chance of
TS>>evolution of PHP to support more "advanced" features (which are common in

There's a lot of chance for PHP to evolve, but if you mean by it that any
feature that you might like would be in without scrutiny - yes, there's
little chance for that.

TS>>other scripting languages, as mentioned). It seems basic OO support is about
TS>>the only thing the PHP community can handle when it comes to expressiveness
TS>>in the language. Oh, well.

It means you probably won't see in PHP every feature that your favorite
other language has. So what? Your favorite other language probably doesn't
have all the features of PHP. The new features for PHP should be checked
if they are good for PHP and can be implemented consistently and
efficiently in PHP.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Terje Slettebø

21 years ago

> From: "Stanislav Malyshev" <stas@zend.com>

> TS>>across, given what what operator overloading is about). As I've

pointed out

> TS>>in other postings in this thread, operator overloading is about much

more

> TS>>than "just" "syntactic sugar". In C++, for example, it enables

important

>
> I think you did not succeed in proving this point. You keep bringing
> examples of how useful it is in C++ - which can be interesting to debate,
> but is entirely irrelevant to PHP, since PHP is different from C++ on many
> levels and tasks that are solved with operators in C++ often even not
> exist in PHP (like "smart pointers", etc.). I still fail to see how it can
> be really useful - in terms of making something that was very hard to do
> before easy to do now - beyond they syntax sugar value.

It's a little hard to bring examples of PHP usage of it, since it doesn't
exist there, and therefore we have no experience with it. However, I saw
someone post a patch about it, enabling overloaded operators in PHP.

> TS>>things such as function objects (being able to pass an object to a

function,

> TS>>for example, and have it behave as a function, enabling functional
> TS>>programming, as well). This is not possible (possibly without jumping
> TS>>through major hoops) in PHP.
>
> Surely it is. Via __call, for example, which is no worse than operator().
> Yes, you could not write it the same syntax as C++ - so what?

An advantage of function objects in C++ is that they can be used where
functions are expected. Nevertheless, there are some features that can be
used to get something similar, such as create_function():

> TS>>However, I see from this and other threads, that there's not much

chance of

> TS>>evolution of PHP to support more "advanced" features (which are common

in

>
> There's a lot of chance for PHP to evolve, but if you mean by it that any
> feature that you might like would be in without scrutiny - yes, there's
> little chance for that.

By all means, I'm all for scrutiny. :) That's why I bring it up, to possibly
stimulate some discussion about it, and, yes, scrutiny. I may learn at least
as much from this as anyone else. Simply put, I'd like to know what the
arguments for and against are, so that, yes, they may be scrutinised.

> TS>>other scripting languages, as mentioned). It seems basic OO support is

about

> TS>>the only thing the PHP community can handle when it comes to

expressiveness

> TS>>in the language. Oh, well.
>
> It means you probably won't see in PHP every feature that your favorite
> other language has. So what? Your favorite other language probably doesn't
> have all the features of PHP. The new features for PHP should be checked
> if they are good for PHP and can be implemented consistently and
> efficiently in PHP.

True. I see what I wrote above was rather harsh. I guess I in a way hoped
that someone would tell me I'm wrong. :) And that the PHP community _is_
interested in improvements in the language (any improvements, these are just
some possibilities), and that possibly what I suggest is not what is found
to be most interesting, but feature xyz may be, or library x. That would
have been fine. I'm here to learn, too.

So, ok, I acknowledge that the community _is_ interested in improvements in
the language, and therefore take back the paragraph you quote above (and any
statements like it).

Regards,

Terje

Stanislav Malyshev

21 years ago

TS>>An advantage of function objects in C++ is that they can be used where
TS>>functions are expected. Nevertheless, there are some features that can be

Depending on what you mean of "expected". You can't use such object as a
function pointer, for example. Yes, you can write Object() and make that
do Object->operator(). In PHP that won't work, because $object() already
has meaning.

TS>>used to get something similar, such as create_function():

create_function is entirely different thing. It actually dynamically
creates a function (which C++ can't do) which you can call by name. __call
handler is much more like - though not entirely - to the operator()
concept.

--
Stanislav Malyshev, Zend Products Engineer
stas@zend.com  http://www.zend.com/ +972-3-6139665 ext.115

Terje Slettebø

21 years ago

(Ditto remark here as the posting I just sent: Please direct any followup
privately)

>From: "Stanislav Malyshev" <stas@zend.com>

> TS>>An advantage of function objects in C++ is that they can be used where
> TS>>functions are expected. Nevertheless, there are some features that can

be

>
> Depending on what you mean of "expected". You can't use such object as a
> function pointer, for example. Yes, you can write Object() and make that
> do Object->operator(). In PHP that won't work, because $object() already
> has meaning.

Yup, that's one issue.

> TS>>used to get something similar, such as create_function():
>
> create_function is entirely different thing. It actually dynamically
> creates a function (which C++ can't do) which you can call by name.

Yes, but they are actually related (although I realise that wasn't clear
from my post): Both function objects and dynamically created functions can
be used as lambda/unnamed functions, for example for an algorithm. E.g
(PHP):

usort( $array, create_function('$a, $b', 'return $a->f() < $b->f()'));

Yes, we can't create functions on-the-fly in C++ (at runtime), but we have
something that can be used in much the same way, and it can also hold state
(something you need to use function "static" or some such to do in PHP),
function objects, and compile-time function object composition. With the
Boost.Lambda library, you may actually do things like:

sort(begin, end, _1 < _2);

The last part creates a function object on the fly (at compile time), which
performs comparison of the elements of the sequence ("begin" and "end" are
iterators).

> __call
> handler is much more like - though not entirely - to the operator()

concept.

You can say that, but you might also say that it's somewhat similar to
create_function(): It "creates" (the impression of a) member function at run
time. ;)

Regards,

Terje

Stig S. Bakken

21 years ago

On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote:

> > From: "Stig S. Bakken" <stig@yahoo-inc.com>
> >
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> > > Andi Gutmans wrote:
> > > > Comments/Flames/Praises to this list :)
> > >
> > >  Just curious: Have you considered adding the operator overloading
> > >  patch [1] by Johannes Schlüter that has been floating around for a
> > >  while?
> >
> > Operator overloading in PHP?  Over my smoking carcass!
> >
> > PHP 5 returns object handles, which lets you do _exactly_ the same thing,
> > only without the obscurity.
>
> You mean $a + $b? add($a, $b) is _not_ "exactly the same thing".
>
> > Nobody needs overloaded operators.  Code should be readable, not
> > cuddly-cute.
>
> Hm, I'm surprised by this response from someone who's name I recognise as an
> active PHP contributor. The answer strikes me as either arrogant and/or
> ignorant (note: I'm not saying you are that, but that's how the reply comes
> across, given what what operator overloading is about). As I've pointed out
> in other postings in this thread, operator overloading is about much more
> than "just" "syntactic sugar". In C++, for example, it enables important
> things such as function objects (being able to pass an object to a function,
> for example, and have it behave as a function, enabling functional
> programming, as well). This is not possible (possibly without jumping
> through major hoops) in PHP.
>
> However, I see from this and other threads, that there's not much chance of
> evolution of PHP to support more "advanced" features (which are common in
> other scripting languages, as mentioned). It seems basic OO support is about
> the only thing the PHP community can handle when it comes to expressiveness
> in the language. Oh, well.
>
> Oh, and the comment about "Code should be readable, not cuddly-cute":
> Operator overloading is about being able to express your intent clearer in
> the code - leading to _more_ readable code than the corresponding function
> alternative (see my arithmetic example in another posting). It has nothing
> to do with cuteness, and everything to do with being to express your intent
> clearly in the code. But it seems the community isn't ready for this. Too
> bad. Maybe in PHP 10.

My take on this is that you are, in many more cases than not, able to
express your intent much clearer with good method names.  This is
especially true if operator overloading were not part of the language
initially.  Your example with complex math is an exception.

Please explain how you see operator overloading making functional
programming possible/easier in PHP?

- Stig

--
"Nearly all men can stand adversity, but if you want to test a man's
character, give him power." - Abraham Lincoln

Terje Slettebø

21 years ago

(I don't mind this discussion, but as several have asked for this subthread
on overloading be ended, it may be best to do so)

On Thu, 2005-02-03 at 19:58, Terje Slettebø wrote:

> > From: "Stig S. Bakken" <stig@yahoo-inc.com>
> >
> Oh, and the comment about "Code should be readable, not cuddly-cute":
> Operator overloading is about being able to express your intent clearer in
> the code - leading to _more_ readable code than the corresponding function
> alternative (see my arithmetic example in another posting). It has nothing
> to do with cuteness, and everything to do with being to express your

intent

> clearly in the code.

>My take on this is that you are, in many more cases than not, able to
>express your intent much clearer with good method names.  This is
>especially true if operator overloading were not part of the language
>initially.  Your example with complex math is an exception.

You're entitled to your opinion, of course.

>Please explain how you see operator overloading making functional
>programming possible/easier in PHP?

By enabling the creation of function objects, which may hold state (unlike
functions, unless you use "static"). One typical feature of functional
programming languages is the ability to do "partial application", i.e.
giving a function less than the arguments it needs, yielding a function with
some of the arguments bound. To illustrate its use, I can give a "simple"
example in C++:

#include <iostream>

class plus
{
public:
int operator()(int a,int b) { return a+b; }
};

template<class T>
class apply1
{
public:
apply1(int v) : bound_1st(v) {}

int operator()(int b) { return T()(bound_1st, b); }

private:
int bound_1st;
};

int main()
{
std::cout << plus()(1,3) << "\n";

std::cout << apply1<plus>(1)(3) << "\n";
}

The first line of main() creates a "plus" object ("plus()"), and calls its
overloaded operator() with 1 and 3, giving 4. The second line creates an
"apply1" object (taking "plus" as a type parameter, and 1 as a constructor
parameter - "apply1<plus>(1)"), and then its overloaded operator() is called
with 3. As the first parameter, 1, is "bound" by "apply1", the result is,
once again, 4. So the above prints "4 4" (separated by newline).

apply1<plus>(1) creates a function object which has bound one of plus'es
parameters, which means it becomes a "1 + ?" function, effectively, or in
other words, a partial application of the "plus" function (object).

Naturally, you may get a similar effect in PHP by using named member
functions rather than operator(). As another poster pointed out, $object()
already has a (different) meaning.

Regards,

Terje

Andrei Zmievski

21 years ago

Attention: you have posted C++ template code on PHP mailing list. Please
pay a $100 fine immediately and carefully proceed to the exit.

-Andrei

On Mon, 07 Feb 2005, Terje Sletteb? wrote:

Christian Schneider

21 years ago

Andrei Zmievski wrote:

> Attention: you have posted C++ template code on PHP mailing list. Please
> pay a $100 fine immediately and carefully proceed to the exit.

Luckily my peril sensitive sunglasses turned black at the first line
before I even managed to read the template part of the code :-)

>>To illustrate its use, I can give a "simple" example in C++:

Now that's one of the funniest jokes I've read on the internals list in
quite a while (-:C

And now we all go and quickly wash our brains with soap so we don't get
evil dreams keeping us up at night.

Sorry, couldn't resist,
- Chris

Marcus Börger

21 years ago

Hello Christian,

Monday, February 7, 2005, 11:59:04 PM, you wrote:

> Andrei Zmievski wrote:
>> Attention: you have posted C++ template code on PHP mailing list. Please
>> pay a $100 fine immediately and carefully proceed to the exit.

> Luckily my peril sensitive sunglasses turned black at the first line
> before I even managed to read the template part of the code :-)

Also called 'Danger-O-Matic-Sunglasses' (from Hitch-hikers-guide-to-the-galaxy)

--
Best regards,
Marcus                            mailto:helly@php.net

Terje Slettebø

21 years ago

> Andrei Zmievski wrote:
> > Attention: you have posted C++ template code on PHP mailing list. Please
> > pay a $100 fine immediately and carefully proceed to the exit.
>
> Luckily my peril sensitive sunglasses turned black at the first line
> before I even managed to read the template part of the code :-)
>
> >>To illustrate its use, I can give a "simple" example in C++:
>
> Now that's one of the funniest jokes I've read on the internals list in
> quite a while (-:C

Did you note I wrote "simple" (in quotations)? To a seasoned C++ developer,
it's rather ordinary/modern C++ code, but it may not be to others.

> And now we all go and quickly wash our brains with soap so we don't get
> evil dreams keeping us up at night.

I see you're not ready for this. Any language, if you're not familiar with
it and its idioms, may seem complicated (and in your case may give you "evil
dreams", apparently). However, what you may see as complicated, people in
the know see as powerful abstractions, which may lead to simpler to
understand code (than without them), again, if you know the language.
However, I see that people here "freak out" when they see C++ code (like I
said, rather different to if someone presented code in another language -
any language - at a C++ forum), so it's pointless to continue with this
here. It was meant to illustrate a point, but that was apparently missed
completely.

Regards,

Terje

Terje Slettebø

21 years ago

>From: "Andrei Zmievski" <andrei@gravitonic.com>

> Attention: you have posted C++ template code on PHP mailing list. Please
> pay a $100 fine immediately and carefully proceed to the exit.

Hehe... I do hope this is a joke (it would seem rather closed-minded,
otherwise). I don't think anybody would have bothered if anyone posted PHP
code on e.g. comp.lang.c++(.moderated), in order to illustrate a point. That
would be stupid.

Regards,

Terje

Andrei Zmievski

21 years ago

>> From: "Andrei Zmievski" <andrei@gravitonic.com>
>
>> Attention: you have posted C++ template code on PHP mailing list.
>> Please
>> pay a $100 fine immediately and carefully proceed to the exit.
>
> Hehe... I do hope this is a joke (it would seem rather closed-minded,
> otherwise). I don't think anybody would have bothered if anyone posted
> PHP
> code on e.g. comp.lang.c++(.moderated), in order to illustrate a
> point. That
> would be stupid.

<sigh> I tried. Perhaps you can return your sense humor for a refund?

-Andrei

Adam Maccabee Trachtenberg

21 years ago

On Mon, 7 Feb 2005, Andrei Zmievski wrote:

> > Hehe... I do hope this is a joke (it would seem rather
> > closed-minded, otherwise). I don't think anybody would have
> > bothered if anyone posted PHP code on
> > e.g. comp.lang.c++(.moderated), in order to illustrate a
> > point. That would be stupid.
>
> <sigh> I tried. Perhaps you can return your sense humor for a refund?

I do hope this is a joke. Otherwise, you will be forced to read
e.g. comp.lang.c++(.moderated) until you pay everyone on this thread
$100.

-adam

--
adam@trachtenberg.com | http://www.trachtenberg.com
author of o'reilly's "upgrading to php 5" and "php cookbook"
avoid the holiday rush, buy your copies today!

Terje Slettebø

21 years ago

> >> From: "Andrei Zmievski" <andrei@gravitonic.com>
> >
> >> Attention: you have posted C++ template code on PHP mailing list.
> >> Please
> >> pay a $100 fine immediately and carefully proceed to the exit.
> >
> > Hehe... I do hope this is a joke (it would seem rather closed-minded,
> > otherwise). I don't think anybody would have bothered if anyone posted
> > PHP
> > code on e.g. comp.lang.c++(.moderated), in order to illustrate a
> > point. That
> > would be stupid.
>
> <sigh> I tried. Perhaps you can return your sense humor for a refund?

Yeah, follow it up with an insult; that'll do lovely. If you had some
insight into human nature, you'd know that humour is very subjective, and
given the feedback I've got from others in this thread (which have _not_
been jokes), it's rather hard to see what's a joke and what's not.

Let me explain: Although I understood that the literal thing you wrote above
was of course a joke, my question was meant to see whether there was a
serious side to the joke, as well. In other words, if people reacted
negatively to this (and, judging from other reactions, it seems so, or at
least, they concentrated on the code, rather than my point illustrated with
it).

I've been known to have a good sense of humour. However, I'm also sensitive,
so when I don't know if something is meant as a joke or not, I don't find it
amusing.

Apparently, this was something you didn't understand, at all, and instead
insult me about something you know _nothing_ about. What have I done to you,
to get an insult from you? How would you feel it if someone else said this
to you? A friggin' immature thing to say.

Regards,

Terje

Andi Gutmans

21 years ago

Terje,

Please take these personal emails off the list.
It's getting cluttered with too much unfocused emails and it makes it hard
for people to keep up with development itself.
Thanks,
Andi

At 10:40 AM 2/8/2005 +0100, Terje Slettebø wrote:

Andi Gutmans

21 years ago

No. I am very much against operator overloading.
It leads to confusion and I can tell you that from a lot of C++ experience
debugging very large applications. The code looks sexy and it's horrible to
debug and understand what's happening.
Andi

At 10:59 AM 2/3/2005 +0100, Sebastian Bergmann wrote: