PHP 5.1

20 years ago by Andi Gutmans — view source — reply

unread

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

20 years ago by Marc Richards — view source — reply

unread

Andi Gutmans wrote:

Comments/Flames/Praises to this list :)

All praise PHP 5.1. All praise PDO.

Marc

20 years ago by Stephan Schmidt — view source — reply

unread

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

20 years ago by George Schlossnagle — view source — reply

unread

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.

George

20 years ago by Christian Stocker — view source — reply

unread

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

20 years ago by Andi Gutmans — view source — reply

unread

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

Andi

At 09:20 PM 2/1/2005 +0100, 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.

Stephan

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

20 years ago by Rasmus Lerdorf — view source — reply

unread

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

20 years ago by l0t3k — view source — reply

unread

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

l0t3k

20 years ago by Andi Gutmans — view source — reply

unread

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:

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

20 years ago by Rasmus Lerdorf — view source — reply

unread

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

20 years ago by Christian Schneider — view source — reply

unread

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

20 years ago by Rasmus Lerdorf — view source — reply

unread

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

20 years ago by Jochem Maas — view source — reply

unread

$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'?

20 years ago by Jeff Moore — view source — reply

unread

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.

20 years ago by Rasmus Lerdorf — view source — reply

unread

Jeff Moore 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

20 years ago by Jeff Moore — view source — reply

unread

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.

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.

20 years ago by Andi Gutmans — view source — reply

unread

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:

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

l0t3k

20 years ago by George Schlossnagle — view source — reply

unread

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

20 years ago by Jay Smith — view source — reply

unread

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.

20 years ago by Gareth Ardron — view source — reply

unread

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.

20 years ago by Ilia Alshanetsky — view source — reply

unread

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:

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

20 years ago by Jay Smith — view source — reply

unread

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.

20 years ago by Andi Gutmans — view source — reply

unread

Any volunteers to review and commit this?

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

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.

20 years ago by Marcus Boerger — view source — reply

unread

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

20 years ago by Andi Gutmans — view source — reply

unread

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

20 years ago by Jason Garber — view source — reply

unread

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

20 years ago by Andi Gutmans — view source — reply

unread

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:

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

20 years ago by Xuefer Tinys — view source — reply

unread

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...)

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

20 years ago by Rasmus Lerdorf — view source — reply

unread

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

20 years ago by Derick Rethans — view source — reply

unread

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

20 years ago by Sebastian Bergmann — view source — reply

unread

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

20 years ago by Derick Rethans — view source — reply

unread

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

20 years ago by Sebastian Bergmann — view source — reply

unread

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

20 years ago by Derick Rethans — view source — reply

unread

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

20 years ago by Pierre-Alain Joye — view source — reply

unread

On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
derick@php.net (Derick Rethans) 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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
derick@php.net (Derick Rethans) 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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

From: "Stanislav Malyshev" stas@zend.com

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.

Yes, but a different way might be used for PHP.

Regards,

Terje

20 years ago by Pierre-Alain Joye — view source — reply

unread

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:

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

20 years ago by Stanislav Malyshev — view source — reply

unread

PJ>>$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;
PJ>>
PJ>>In my example (a date object, day being 31), at this I do not know
PJ>>if one is assigning 32 to the property or if it's the result of
PJ>>incrementation (or decrementation from 1 to 0).

That's why one should use $date->NextDay() and $date->PreviousDay() and
neither ++, nor --, nor manipulating properties directly :)

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

20 years ago by Derick Rethans — view source — reply

unread

PJ>>$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;
PJ>>
PJ>>In my example (a date object, day being 31), at this I do not know
PJ>>if one is assigning 32 to the property or if it's the result of
PJ>>incrementation (or decrementation from 1 to 0).

nor manipulating properties directly :)

I know you put a :) there, but if you really mean it then you should NOT
be using PHP! Reason: PHP isn't about OO cosyness - it's about solving a
Web problem.

Derick

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

From: "Derick Rethans" derick@php.net

Oh, hello. I recognise your name as one of the other authors of the book
"PHP 5 Power Programming", which I've recently got, and which looks very
good. It seems like all the "big guns" are on this list. :) (similar to
comp.lang.c++.moderated and comp.std.c++ for C++).

PJ>>$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;
PJ>>
PJ>>In my example (a date object, day being 31), at this I do not know
PJ>>if one is assigning 32 to the property or if it's the result of
PJ>>incrementation (or decrementation from 1 to 0).

nor manipulating properties directly :)

I know you put a :) there, but if you really mean it then you should NOT
be using PHP! Reason: PHP isn't about OO cosyness - it's about solving a
Web problem.

Hm, from several postings, I've detected something of a - I don't quite know
how to say it in English - resentment against OO on PHP lists and
newsgroups. Why is this? Unfamiliarity with it, or what? It typically gets
expressed as derogatory expressions like "cosyness" or "cuteness", as a
"quick and dirty" attempt to discredit something without any proper
argument.

Now, whether or not you're accessing properties has nothing in particular
with the language you use; it's a design issue. Oh, and it has nothing to do
with "cosyness" and everything to do with program robustness, correctness,
encapsulation, decoupling of interface from implementation, and other
time-honoured software development principles (which are independent of any
particular "paradigm", such as OO).

Most software development experts aren't "religious" about the issue of
accessor functions. If your class is basically just a value container,
without any class invariants to maintain, then accessing properties directly
may be a reasonable way to do it.

In the case of a date object, it's a really bad idea to be able to access
the properties directly, because, as it says in the quote above, you may
e.g. increment the day beyond the end of the month, setting it to a negative
value, etc. In short, it's an error-prone and bad design.

Since you think it's a good idea to have public properties for date
objects, I'd like to hear your reasons for it.

Regards,

Terje

20 years ago by Darrell Brogdon — view source — reply

unread

I don't think its really a resentment (for the most part) against OO in
PHP even if it seems that way. One of the stated goals of PHP is to
have a low learning curve and this is something it does very well. I'm
sure you can agree that OO concepts typically don't fit that criteria
which is why you can still build complete PHP apps without using any OO
concepts. So the seemingly resentful attitudes should probably be
viewed as one of "lets do our best to keep this as simple as possible
while retaining the power it is intended to provide".

Hm, from several postings, I've detected something of a - I don't
quite know
how to say it in English - resentment against OO on PHP lists and
newsgroups. Why is this? Unfamiliarity with it, or what? It typically
gets
expressed as derogatory expressions like "cosyness" or "cuteness", as a
"quick and dirty" attempt to discredit something without any proper
argument.

--
Darrell Brogdon
http://darrell.brogdon.net

20 years ago by tslettebo@broadpark.no — view source — reply

unread

From: "Darrell Brogdon" darrell@brogdon.net

I don't think its really a resentment (for the most part) against OO in
PHP even if it seems that way. One of the stated goals of PHP is to
have a low learning curve and this is something it does very well. I'm
sure you can agree that OO concepts typically don't fit that criteria
which is why you can still build complete PHP apps without using any OO
concepts.

Yes, the gentle learning curve of PHP, and that you don't have to use OO is
a good thing.

So the seemingly resentful attitudes should probably be
viewed as one of "lets do our best to keep this as simple as possible
while retaining the power it is intended to provide".

Ok.

Regards,

Terje

20 years ago by Christian Schneider — view source — reply

unread

Derick Rethans 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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

Derick Rethans 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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

From: "Stanislav Malyshev" stas@zend.com

TS>>When you say "typeless", i think you mean "not statically typed".

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

...Because PHP has types, so I felt it was a misnomer to call it "typeless".

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.).

No, you don't have to go that far. For starters, one could allow function
(and possibly operator) overloading, based on type hints. The following is
legal PHP5:

function something(SomeClass $value) { ... }

We could make the signature (currently only the name) extend to include the
parameters, as well, so we could allow the following, without errors about
duplicate definition:

function something(AnotherClass $value) { ... }

That's it. That's all you need for function overloading. You can safely keep
the lid on that can of worms of yours. :) If we were to extend this, I'm
sure we'd find a way to deal with any "worms".

And this would seriously complicate function call logic

It would increase the complexity somewhat, since you have to perform
overload resolution. However, how much on an impact this would have on
execution speed remains to be seen.

which is very bad, because, unlike
statically-typed language, we can not offload this complexity to one-time
compile stage.

Right.

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.

I know. My point was that, as we have type hints, we have a way to
differentiate functions, since they may now both have variable types, and
number of parameters.

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?

It was a reaction to the oft-mentioned argument that essentially says: "We
don't need more advanced features." I got that feeling when you said "Using
good old methods will never fail you.". However, I may have misread you. If
taken to the limit, you don't need more than ones and zeroes to program, but
it sure makes it easier to have higher levels of abstraction. Anyway, it
seems we agree on that.

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.

I've replied to this in the reply to that posting, so I won't go into it
here.

Regards,

Terje

20 years ago by Stanislav Malyshev — view source — reply

unread

TS>>No, you don't have to go that far. For starters, one could allow function
TS>>(and possibly operator) overloading, based on type hints. The following is
TS>>legal PHP5:

That will already open the can of worms. And make each function call to go
through all the hoops of signature matching.

TS>>That's it. That's all you need for function overloading. You can safely keep

Then you couldn't make operator+ that adds an integer to complex (and make
it different from one adding complex to complex ) - because typehints do
not include integers.

TS>>sure we'd find a way to deal with any "worms".

Sure. Just make another C++ and you are OK. The problem is we don't want
another C++.

TS>>overload resolution. However, how much on an impact this would have on
TS>>execution speed remains to be seen.

Exactly. Do you have any base to claim the speed impact would not be
serious? Bring it forward.

TS>>It was a reaction to the oft-mentioned argument that essentially says: "We
TS>>don't need more advanced features." I got that feeling when you said "Using

Nobody ever said "we don't need more advanced features". You know
perfectly it is not true. What was said is that we probably don't need
this particular feature. This has no relation to discussion of any other
feature or discussion about having features in general. Having discussion
in family-fight style along the lines of "You never listen to me!" rarely
results in anything useful.

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

From: "Stanislav Malyshev" stas@zend.com

TS>>No, you don't have to go that far. For starters, one could allow
function
TS>>(and possibly operator) overloading, based on type hints. The
following is
TS>>legal PHP5:

That will already open the can of worms. And make each function call to go
through all the hoops of signature matching.

Yes, that is a concern, especially when it's done at run-time.

TS>>overload resolution. However, how much on an impact this would have on
TS>>execution speed remains to be seen.

Exactly. Do you have any base to claim the speed impact would not be
serious? Bring it forward.

No, which is why I said that it "remains to be seen" what impact it would
have, which means I'm not claiming anything one way or the other.

TS>>It was a reaction to the oft-mentioned argument that essentially says:
"We
TS>>don't need more advanced features." I got that feeling when you said
"Using

Nobody ever said "we don't need more advanced features". You know
perfectly it is not true. What was said is that we probably don't need
this particular feature. This has no relation to discussion of any other
feature or discussion about having features in general.

True.

Anyway, there have been requests for ending this sub-thread on overloading,
etc., so I suggest that any further discussion, should it be wanted, is done
off-list.

Regards,

Terje

20 years ago by Andi Gutmans — view source — reply

unread

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

20 years ago by Wez Furlong — view source — reply

unread

+1.

Nothing to see here, move along.

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

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.
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

20 years ago by Pierre-Alain Joye — view source — reply

unread

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?

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

20 years ago by Johannes Schlueter — view source — reply

unread

Hi,

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

Stanislav Malyshev wrote:

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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

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.

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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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:

$result=$c1.multiply($c2).divide($c1.add($c2));
$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

20 years ago by Derick Rethans — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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

20 years ago by Stanislav Malyshev — view source — reply

unread

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

20 years ago by tslettebo@broadpark.no — view source — reply

unread

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

PHP 5.1

Stephan

Stephan

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

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