Marcus Boerger wrote:
- Add a new severity E_DEPRECATED
Sounds like a good idea, +1 on the whole thing.
. E_STRICT any rule that reflects common strict standards, like OOP theory
that is considered harmless if not followed. For example the combination
'abstract static' makes no
Richard Lynch wrote:
On Wed, October 25, 2006 9:56 am, Christian Schneider wrote:
Another idea (I haven't seen skimming through the replies):
Move use of undefined variable, property and index from E_NOTICE to
E_STRICT as it is a coding style question some people use to find
typos.
I'd
Andi Gutmans wrote:
Maybe in a purists view it's not great, but in real life, many many many
users run more than one application on the same PHP server. Not supporting
per-request Unicode in PHP 6 is going to be a huge mistake and will just
screw our users, most of them not purists nor hackers..
Sebastian Bergmann wrote:
It would be nice if it could be decided who is in charge of this
extension. Since Rasmus and Derick did all the initial work on the
extension I think it should be them, and not Pierre.
I agree that we need someone in charge. But I also think that the
initial work
Pierre wrote:
This patch is more than only changing the API to fit to our decisions.
I know. That's why Derick's patch would have to be on par to be competitive.
The (bad) joke is to be here talking again about something we agreed
on two weeks ago.
While I agree with you the problem is that
Marcus Boerger wrote:
the short form is, use interfaces. And the long form is read the upgrade
file and find out to use interfaces :-)
I don't understand how interfaces are connected to my proposal, please
explain.
Personally I don't need the strict OO checks for matching parameter
lists
In the discussion about parameter checking in 5.2 I proposed to relax
the checks a tiny little bit: Don't test static functions (e.g. useful
for factory methods) and allow adding default values to functions (the
object of the inherited class still accepts the same parameters as the
base class). A
Pierre wrote:
The flag allows arrays and always returns an array. It is obvious as
if you allow array or scalar, you have to use is_array, that's a step
we easily drop internally by always returning an array. I do not see
the point to have ALLOW_ARRAY and FORCE_ARRAY. It is confusing.
I agree
Pierre wrote:
Proposal:
**
I. Availalbe functions:
---
* input_get
Gets variable from outside PHP or from a userland variable and
optionally filters it using one filter and its options or flags. It
accepts only scalar by default, array can be returned using
Pierre wrote:
It always returns an array when FILTER_FLAG_ARRAY is given. Even when
the input value was a scalar. It spares yet another is_array/isset
test. And it accepts only scalar by default or when FILTER_FLAG_SCALAR
is given.
Makes sense but the example shows:
$args = array(
...
Richard Quadling wrote:
I agree on this. From my reading of some the issues around unicode you are
far better off simply saying PHP6 is unicode only. A lot of scripts that
You didn't address the point of people who don't need Unicode but need
the fast possible version (because slower running
I get a segfault with PHP 5.2.0RC2 in CLI mode (Apache module seems to
work) and APC 3.0.11 (without APC it works fine). Is this a known
problem (maybe even fixed in CVS) or is it worth investigating?
Some info:
./configure --with-apxs2=/www/server/bin/apxs --prefix=/www/server
Rasmus Lerdorf wrote:
An opcode cache doesn't help a whole lot in CLI mode. You can turn it
off in that mode with:
apc.enable_cli=0
Doesn't help, I get the segfault anyway, probably before the setting is
already considered.
And yes, there are a couple of PHP 5.2 incompatibilities we
I'm having troubles with ext/openssl.c and OpenSSL 0.9.7g on SuSE 10:
EVP_PKEY_EC is not defined.
The attached patch fixes the problem for me.
- Chris
Index: ext/openssl/openssl.c
===
RCS file:
Derick Rethans wrote:
Sure, but then that code won't run on older versions of PHP (5.1 f.e.)
anymore, so it is not a good solution.
The same was true for PPP.
But like you I prefer the E_STRICT version without modifying the
language though. But I'm sharing Lukas' concern about the definition
Lukas Smith wrote:
So then the only option is to introduce a
i-dont-want-to-care-about-oo-in-my-classes-mode for the people who
simply don't care.
yes .. it should be possible to set this on a per class basis. and
children should be able to change the mode. classes in lax mode might
also
Rasmus Lerdorf wrote:
trying to meet a new class of expectations. We have kids coming out of
universities today who barely know what procedural programming is. All
they know is OOP and we want to give them something that meets their
expectations. We have to be careful that we don't ignore
Andi Gutmans wrote:
For constructors it actually makes sense because at the time of
instantiaton, you know what the concrete class is. It is very common for
constructors to be very much different in polymorphic classes.
What about factory methods? It makes sense there too.
I could also
Steph Fox wrote:
Rasmus, I'm sorry but I can't agree with you. When we get namespacing
it'll make perfect sense to have PHP::Foo(). Until then, it makes no
sense whatsoever to me to mess about with plain names for root classes.
Since the early days of PHP4 everybody is using the plain names
Andi Gutmans wrote:
I don't think question is only in regards to Date.
I think it's a bigger question on what the standard is for internal classes.
I couldn't agree more. The main question is who the unprefixed namespace
belongs to. I'd say it's either the core or the application but
Derick Rethans wrote:
On Tue, 18 Jul 2006, Ilia Alshanetsky wrote:
And we need to get a bit on track as well. Let's outline possible options for
names, vote on them and move on to more important things.
The two naming options available so far are:
Option A: DateTime DateTimeZone
That one
Tobias Schlitt wrote:
using string manipulation, I now patched pathinfo() to provide the
filename without extension per default with key filename.
Find the patch here: http://schlitt.info/misc/pathinfo.patch
If the patch is considered then I would propose to also return the key
filename if
Marcus Boerger wrote:
-/* $Id: zend_compile.c,v 1.647.2.27.2.5 2006/05/27 18:23:48 johannes Exp $ */
+/* $Id: zend_compile.c,v 1.647.2.27.2.6 2006/05/29 20:06:43 helly Exp $ */
#include zend_language_parser.h
#include zend.h
@@ -2028,8 +2028,9 @@
if (parent_flags ZEND_ACC_ABSTRACT)
Marcus Boerger wrote:
whatever the patch looks like, it is a change from 5.0.0's E_STRICT
I was just noticing a probable bug in the patch and felt like reporting
it, that's all. I didn't want to start a discussion about migration
paths but since you asked for my opinion, here it is...
One caveat with making a static call to a non-static function a fatal
error is that it will make use of static calls impossible for code which
wants to be PHP4 and PHP6 compatible, no? You probably don't care but I
still wanted to mention it.
E_STRICT is nice for people who are able to move
Marcus Boerger wrote:
There is no way you can write heavy oo using code that supports PHP 4
and PHP 5.2 without a version check every here and there, so i don't see
I'm not talking about heavy OO code. Just very basic one which static
methods are used as sort-of namespaces. And that works
Jasper Bryant-Greene wrote:
Christian Schneider wrote:
PS: There are no plans to make non-static calls to static methods
illegal, right?
What is the point in that? What advantage do you get using
$this-someMethodName() [non-static call] over self::someMethodName()
[static call]?
self:: does
Derick Rethans wrote:
On Tue, 23 May 2006, Zeev Suraski wrote:
I know I'm a late bloomer on this one, but when did we discuss the
discontinuation of ze1 compatibility mode within the 5.x branch? I recall we
agreed to remove it for 6.0, but removing such a thing in 5.x seems very
Ron Korving wrote:
I'm a big fan of this keyword. No , and this is in fact clearer and
better than the readonly keyword I advocated. Great idea :)
Just a quick question because I wasn't able to test any implementation
yet: Does the new keyword conflict with functions/methods/properties of
Ron Korving wrote:
Like you, I don't see why a 'readable' keyword should make things any more
complicated for beginners, because indeed, it is optional and beginners will
simply not use it. To me, this only shows the strength of PHP: suitable for
beginners and suitable for the enterprise.
Marcus Boerger wrote:
i changed from readonly to readable, which means the new keyword makes it
public for any read access, that is:
So much for readable being obvious (i.e. you have to explain it).
private readable $abc;
- class itself can read and write
- public for everybody
[EMAIL PROTECTED] wrote:
I really do not see the need to keep telling php I'm
refering to the properties and method of the class I'm
already in, when php 5 should be able to deduce this from
the context of the class I'm coding in.
This would turn all local variables into global ones in
First of all I was simply proposing a very generic concept without
bothering about the implementation on purpose. If it's not feasible then
simply ignore it.
Marcus Boerger wrote:
caching? There is nothing to cache. And even if we would do that we would
make every string an object since we
Andrei Zmievski wrote:
I am not sure how we can optimize [] to be faster than the iterator
approach. Food for thought?
You could cache the last position (PHP- and Unicode string index) and
start from there. This assumes that most accesses are (more or less)
sequential. If you can step
Etienne Kneuss wrote:
Notice that this behavior can be reproduced using only prefix increment
operators.
Is that also expected to give undefined results ?
Yes, see
http://en.wikipedia.org/wiki/C_syntax#Undefined_behavior
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To
Lukas Smith wrote:
compared to the many features recently added. But then again it seems
that the bulk of people who have the power to actively stear PHP
disagree. So I see little reason to continue this discussion.
Nice try, but you forgot Quirk's exception ;-)
- Chris
--
PHP Internals -
Jason Garber wrote:
Here is a coding idea for you, in case you hadn't considered it...
function highlight($text=NULL, $needle=NULL, $strip_links=NULL, ...)
{
is_null($text) $text = SOME DEFAULT VALUE;
is_null($needle) $text = SOME DEFAULT VALUE;
is_null($strip_links)
Ron Korving wrote:
Named parameter example:
Your example misses the main advantage of named parameters IMHO: Sets of
parameters you don't want to or can't explicitely list because they are
not know yet.
function adduser($params)
{
if (!is_array($params)) throw new Exception('No
Ilia Alshanetsky wrote:
The attached patch is a possible solution to the date *crisis*, it
renames the class to PhpDate to avoid any namespace conflicts with pear
or custom user classes called date.
While there already were objections either voting for removing the class
altogether for now or
Marcus Boerger wrote:
PS: I'd rather have : for namespaces with the whitespace restriction for
? a:x : b:y than the confusing (escaping characters outside of a
string?) backslash.
And kill trillions of php scripts, how funny. Think before writing.
From Jessie's statements I was assuming
Lukas Smith wrote:
Marcus Boerger wrote:
That conclusion means stay with date in ext/date and have pear learn the
lesson by making the same mistake in core. Once again the only
solution is
namespacing.
indeed.
though this mistake applies to all of PEAR at this point ..
As has been pointed
Derick Rethans wrote:
I didn't say that my code is more important, but if we don't get the
date class now, we will get it in 5.1.1 and then break your code - so
You're stating this like a fact. Date _can_ be renamed, there's nothing
sacro-sanct about this class.
Just to illustrate some
Derick Rethans wrote:
I don't see so, calling the class date is the only proper name for it.
Oh, just realized another little detail: Why the heck was the class
called date instead of Date? Creating case-sensitivity legacy at this
point in time is something which shouldn't have slipped past
Ilia Alshanetsky wrote:
Defining classes/function with generic names will always be a problem as
they may end up conflicting with same constructs from other libraries or
PHP itself.
Sure. But that doesn't change the fact that a class named date is
*known* to cause conflicts. And that the core
Marcus Boerger wrote:
here again namespaces would be perfect. Given a lib that doesn't prefix
you'd simply do:
namespace LibNameHere { reqire some_lib_include; }
and be done...wohooo :-)
Only if newly introduced PHP core classes use a namespace too. You'll
have to use PHP\Date (or the like)
Sara Golemon wrote:
TBH, I was surprised to see this on the table in the first place myself...
To me the summary of events looks like:
1) People disagree whether goto is A Good Thing
2) PDM discusses it and settles for a compromise solution
3) internals removes the restrictions of the
Jochem Maas wrote:
so I can only assume that the ability to declare ctor signatures have
been left in because they do no harm regardless of whether it is
'correct'.
If I remember correctly then one reason to have constructor signatures
is for object factories: You specify that an object to
Derick Rethans wrote:
discussing the things we want to do for PHP 6. Partly because of the
The whole list of decisions is very reasonable, congratulations!
My only gripe is about the removal of curly braces for string offsets: I
very much like the way you undeprecated var ('As there is no
Sascha Schumann wrote:
16 Nov 2005, PHP 5.1 Release Candidate 5
- Added an E_STRICT warning on the usage of {} for accessing of string
offsets.
(Ilia)
I suggest removing that warning immediately until the matter
is resolved.
I second that as people on the list here are undecided
Rasmus Lerdorf wrote:
Very few people converted to using {} so the argument about reading old
code doesn't really hold. If you go and grep through all the public
code out there, pretty much none of it uses {} for character offsets.
I'd like to cite Andi here:
Regarding BC breakage. I'm not
Ants Aasma wrote:
+-0 on the foreach issue, but with the SPL Iterators I can see where
Marcus is coming from.
Ok, I can see the reason behind it now as casting to array is not an
option for objects with SPL Iterators. One little side-note: Programmers
will still have to do an if($obj) check
Marcus Boerger wrote:
i would like to change foreach a tiny bit. Actually i don't like the
warning when using foreach with null.
The way we use NULL in PHP should result in no warning here. The patch for
Can you elaborate on the The way we use NULL in PHP part?
IMPW (In my PHP world) null
Derick Rethans wrote:
Yes, but thinking that PHP 4 OO code runs on PHP 5 is an illusion
anyway.
No, it's not. What are you talking about? We've been happily using PHP4
with OOP for years. That's basic OO like encapsulating data and
inheritance to extend behaviour. Nothing of that fancy
Marcus Boerger wrote:
E_STRICT in 5.0, 51 is the least thing we need to do and probably we should
simply stop supporting 4.4 otherwise we never have our user base upgrade.
While we would love to upgrade to PHP5 there is one killer for us so far:
None of the open caches (Zend cache is not an
Jani Taskinen wrote:
On Tue, 4 Oct 2005, Christian Schneider wrote:
And the code _does_ work with PHP5.
il·lu·sion:
1. An erroneous perception of reality.
2. An erroneous concept or belief.
3. The condition of being deceived by a false perception or belief.
4. Something
Jani Taskinen wrote:
Yes, but OO in PHP 4 is illusion.
Ok, I see, I replied to a troll. Silly of me. Won't happen again after
this one, I promise.
Nobody's bashing you for using PHP. Just for using PHP 4. :)
Are you reading my posts? Oh no, I forgot, you're just trolling.
Over
Lukas Smith wrote:
to keep customers. This half-assed attempt at maintain BC is what is
really causing major problems.
The problem would be that this new PHP would be a wild mix of all
different changes. While I wouldn't mind a shiny new PHP with
-references removed altogether which always
Derick Rethans wrote:
pointless - I would even go as far as disallowing passing $this by
references to a function - where the reference has to be ignored again,
This would be needed to have something like
function setfoo($obj)
{
$obj-foo = 42;
}
[...]
$other-setfoo($this);
in a way
Marcus Boerger wrote:
php 4 code is wrong in this and we don't want to support the errors
forever.
Programming is like sex: One mistake and you have to maintain it for the
rest of your life (-:C
Sometimes I wish I would have insisted more in Nov. 1999 when I brought
up the reference vs.
Helgi Þormar wrote:
So in a way I agree with Jani, specially since many distros are already
moving to 5.x
Maybe you should look at the installed bases of PHP instead of the PHP
version distributed with the latest distros. Anyone got current stats on
that?
And no, I don't believe in forcing
Marcus Boerger wrote:
[EMAIL PROTECTED] /usr/src/PHP_5_1 $ php -r 'class T{function f($x){}} class U
extends T{function f($x=2){}}'
make: `sapi/cli/php' is up to date.
Strict Standards: Declaration of U::f() should be compatible with that of
T::f() in Command line code on line 1
[EMAIL
Christian Schneider wrote:
Even more so for function V::f($x,$y=false) to
provide extended functionality to T::f($x) for code which knows about it
Ok, forget that part, I made a typo when testing this ;-)
Apologies,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
Jochem Maas wrote:
I would see this as a optional addition to the syntax of interfaces...
i.e. everything works as before but you can add default function bodies
which would behave as if it was defined in each class that implements
the given interface.
if this is a truely evil concept I would
Marian Kostadinov wrote:
public getter fullName { // may also have ()
return {$this-firstName} {$this-lastName};
}
public setter fullName ($value) { // may also not have ($value) but
a special var.
list ($this-firstName, $this-lastName) = explode (' ', $value, 2);
}
This can be
Derick Rethans wrote:
I updated the proposal:
http://files.derickrethans.nl/property_overloading.html
If nobody as any better idea on how to solve it I'd like to start
implementing it.
I seem to remember that we had some voices here stating that the current
mechanisms are sufficient. Adding
Derick Rethans wrote:
If you would have properly read the proposal you see that there are 3!
problems with it. And instead of whining about things, I actually spend
some time of contributing with patches too.
Let's agree to disagree. I easily work around these 3 problems here,
so my patch
Derick Rethans wrote:
I think we shouldn't go overboard with all the suggestions. We do want
to ship the Unicode PHP this year - and just focussing on Rasmus'
initial list seems the best way to me.
I agree that the whole discussion went a bit overboard but on the other
hand while Rasmus'
Rasmus Lerdorf wrote:
4. Include an opcode cache by default. A lot of work has gone into
pecl/apc recently, but I am not hung up on which one goes in.
Big +1
9. Named parameters. Preferred way would be via array()-less array
collation as we are already using this in our production
George Schlossnagle wrote:
Huh? Perl doesn't have true support for this anyway, just a simpler
syntax for hashrefs. If you want Perlish named params this is 100%
identical to doing
foo(array('id' = 42, 'name' = 'foo'));
If you are using this a lot then syntactic sugar does make a
Christian Schneider wrote:
What I don't like about Python at all is that AFAIK you can't call a
method with parameters not declared in the function definition.
Oops, Python does allow this with a *parameter or **parameter. Missed
that part when reading the specs :-)
- Chris
--
PHP
Zeev Suraski wrote:
I believe we mentioned once the possibility of adding another error
level, which is fatal - but still catchable by set_error_handler().
What actually would be the same as having a try block around your
application.
Right, which is infinitely better. It does not
Derick Rethans wrote:
On Wed, 10 Aug 2005, Ron Korving wrote:
In order to create binary string literals, a new syntax is necessary:
prefixing a string literal with letter 'b' creates a binary string.
The b-prefix for binary strings is great, but how does that work with a
function like
Derick Rethans wrote:
On Mon, 8 Aug 2005, Sebastian Bergmann wrote:
Derick Rethans schrieb:
Throwing two different kinds of Exceptions is evil.
Just as evil as allowing SPL to be disabled.
Not really. SPL is only for people that actually want to use Java.
I thought that's what exceptions
Derick Rethans wrote:
class. The magic methods are responsibly for:
- checking if the property actually exists
This is something I wouldn't encourage as one of the virtues of fully
dynamic languages is the lack of checking this. Otherwise what happens
if e.g. one inherits such a class to
Magnus Määttä wrote:
And the much needed goto for the next one (5.2/5.5/6.0 or whatever it will be) ?
Much needed? Matter of taste as lots of existing PHP code proves :-)
What happens if you goto into a loop? I'd rather avoid this mess.
-1 from me.
- Chris
--
PHP Internals - PHP Runtime
Zeev Suraski wrote:
If it was an issue that everyone and their dog was bumping into, then I
may have thought differently - but it's an issue that is rare enough,
and can be worked around. And those that really need it to be fixed -
can use the patch.
As we have run into segfaults with
Derick Rethans wrote:
If you decide not to fix the 4.x branch then we'd minimally need an easily
accessible document describing the known problems and work-arounds IMHO.
As I tried to do that in our large code base, I would say that's totally
not possible to do. There is no way you know
Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
Oops, and here a patch without the debug fprintf :-)
- Chris
Index: ext/standard/var_unserializer.c
Derick Rethans wrote:
On Tue, 17 May 2005, Timm Friebe wrote:
Fix
===
Allow anything the parser allows, [a-zA-Z_\x7f-\xff][a-zA-Z0-9_\x7f-\xff]*
Do you have a patch? :)
I attached a patch for ext/standard/var_unserializer.{c,re}
- Chris
Index: ext/standard/var_unserializer.c
Duncan McIntyre wrote:
http://www.calligram.co.uk/oss/Attributes
In your example I fail to see how
@[ WidgetType(Select);
AllowableValues(array(Current,Savings)); ]
is different from the good old
var $WidgetType = Select, $AllowableValues = array(Current, Saving);
apart from looking weird
Duncan McIntyre wrote:
It's different because in your example there is no way of knowing that
$AllowableValues refers to $WidgetType.
My solution would be
var $attributes = array(
'accountType' = array(
'Type' = Select,
Hendy Irawan wrote:
database because the metadata is already built-in. Just a rough
sketch:
[columnType: VARCHAR, size: 20] public $name;
[columnType: DATE] public $birthDate;
We do exactly this in PHP 4 already. The base class gets the meta-data
from the DB and stores it in $this-_fields. No
Moriyoshi Koizumi wrote:
I modified your patch so it can capture the position where the
supposed data begins into the constant __HALT_PHP_PARSER__.
Sounds like a good idea to me as all the manual work to guess the start
of the data look a bit kludgy to me.
?php
$fp = fopen(__FILE__, 'rb');
Andi Gutmans wrote:
Yeah I would go and over-engineer this patch.
I agree with you guys, I was just brain-storming ;-)
It's not exactly a general purpose patch especially when it comes to
web. So I think it is already questionable how many ppl would actually
use it. Taking that an
L0t3k wrote:
In about a month or so, i'll start work on an extension implementing a file
format which allows for bundling all resources related to a app (including
I'd very much recommend using an already existing file format, e.g.
PEAR::PHP_Archive (uses tar) or something based on zip.
The
D . Walsh wrote:
Here's a working solution, build with the command gcc create_php_logo.c
-o create-php-logo
The same could be done more easily in PHP in a couple of lines, e.g.
#!/usr/bin/php
?php
echo #define CONTEXT_TYPE_IMAGE_GIF \Content-Type:
image/gif\\n\nunsigned char .
D . Walsh wrote:
Now since this appears to be a separate stand-alone package installed by
pear, why couldn't it be installed and functional, seems that files are
missing and this is why it doesn't appear to function?
I don't think this has anything to do with PHP internals so please take
this
Matthew Charles Kavanagh wrote:
Perhaps you're not seeing my point, or perhaps you don't care about
users? I speak as a developer, not as some guy with a crap webhost, and
So according to you every single extension should be put bundled and
installed by default?
If not, then someone has to draw
Ron Korving wrote:
$foo = emptyor($foo, bar);
I'm not really sure that you'd use this for. Set $foo to either the
original value (if $foo was empty before) or bar? Is that empty as in
empty()? So you could end up with null, , 0, 0, false or bar?
- Chris
--
PHP Internals - PHP Runtime
Derick Rethans wrote:
My experience is that most (OO) code doesn't work when moving anyway...
so this is a bad excuse andi ;-)
If you turn zend.ze1_compatibility_mode on (and a lot of people have to
do that) then the situation is a bit better. Which brings me to the
point that all those E_STRICT
Hey Ante,
Ante Drnasin wrote:
I would just like to hear you oppinions about something like
this...(please don't shoot me :) )
ex1:
function AddToDb(mysql_scape_string($text)) {
I'd say it's not too useful but opens up a can of worms:
- You're adding code to a declaration, IMHO confusing
- How
Andi Gutmans wrote:
PHP has long suffered from poor implementations of some of the DB
extensions and good implementations of others. PDO is a good opportunity
to unify the extensions and have a common code base so that bug fixes
Excuse my ignorance, maybe I missed the answer to Lester's
Andi Gutmans wrote:
What's the status of 2.6.x in Linux distributions? Is it already
standard in the latest SUSE/Redhat distros?
SuSE 8.1: libxml2-2.4.23
SuSE 8.2: libxml2-2.5.3
SuSE 9.0: libxml2-2.5.10
SuSE 9.1: libxml2-2.6.7
SuSE 9.2: libxml2-2.6.12
I'd say that at least SuSE 8.2 and 9.0 are
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
Benj Carson wrote:
My opinion may not carry any weight here, as I'm just a user of PHP, but
this discussion has given me a few ideas. As Ron and Val (and others) have
pointed out, there's no way for PHP to know how an *input* value is going
to be used. Would it perhaps be better to filter
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
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
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
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
Torsten Roehr wrote:
Something so straightforward and fundamental should be possible!?!
Maybe is isn't as fundamental as you think? I never came across this
problem in years of PHP programming. But then again I use classes with
static calls for nothing but separate namespaces :-)
I'm pretty
301 - 400 of 568 matches
Mail list logo
