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
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
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
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,
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
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
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
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
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:
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
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
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
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'
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
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
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
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.
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
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
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
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
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
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
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
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)
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
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
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)
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 -
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
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
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
[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
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
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
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
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
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...
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
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
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:
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
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
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
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
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:
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
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
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(
...
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
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
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
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
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..
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
Ilia Alshanetsky wrote:
Thanks to Hannes we have a fairly complete list of changes in the error
conditions, so far people who have commented out it did not appear to
have identified anything objectionable. We need to make a decision on
how to proceed, either to roll 5.2.0 now or wait another
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
Now given Liskov
rules you can as well add default parameter
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of the
code to be written (applications) instead of a small, controllable
subset (core and libraries).
When developing a
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:18 AM, Christian Schneider wrote:
Ilia Alshanetsky wrote:
Avoid common namespaces and you'll make your application futureproof.
I'm still wary of this approach because it puts the burden on 99% of
the code to be written (applications) instead
Marcus Boerger wrote:
We had problems with Date, DateTime and Time as all of those are common.
I'm well aware of this and the discussion around it.
Should we name a class that represents data and time info name after say
'PhpDateTimeFart' so that there is no problem? Because if you think
Marcus Boerger wrote:
Liskov applies to static methods as soon as calls via objects are common
which is true for PHP.
This is common in PHP and you consider this good practice? Interesting,
wasn't what I would have expected...
I didn't say it is good practice, god behave :-)
So you're
Ilia Alshanetsky wrote:
When we were picking a name the discussion was public on this very list
and based on our analysis of what names people were using in their
application and what would be an ideal name DateTime was picked.
I'm not questioning this decision. I'm talking about the policy
Ilia Alshanetsky wrote:
On 4-Nov-06, at 11:55 PM, Christian Schneider wrote:
But my favourite solution would be to
a) have namespaces handling this issue
Not happening in 5.2 branch.
I know. I'm talking about a long term solution.
b) not introducing (many) more core classes before
Hello Marcus, hello Ilia,
now you two got me confused:
Marcus Boerger wrote:
we have the same problem for functions since years, why is there suddenly
such a big problem with classes now? All new php/pecl classes will follow
one of the following rules:
- Prefix with the extension name
-
Ilia Alshanetsky wrote:
There are no rules there is just one rule, that's not even specific to
PHP when you think of it. It is generally considered to be a good
practice to prefix your code with app name or similar to avoid conflicts
with other libraries and/or applications. When it comes to
Ilia Alshanetsky wrote:
And your point is what? There are even more rules you need to obey while
My point is: Fewer rules make things easier to learn and use.
Well, almost: DateTime is a date class, not a time class.
Actually it works with both date time and calling it datedate seems
ini_set('humour', On);
Richard Quadling wrote:
Type hinting is part of the documentation. Sure, hungarian notation of
variable names (where the type is represented within the variable name
itself) is a good start, but when you get to things like a 4d array of
I wouldn't have expected anyone
Richard Quadling wrote:
And so why are we losing register_globals? For a LOT of code they work
and removing rg is sure as hell a BC for a lot of code. And we move
This was done for *good* reason. You don't gain a lot of security (or
even code clearity/brevity) by changing fgets. That's the
Ilia Alshanetsky wrote:
Just because behavior of something had changed in php6 does not mean it
should change in php5 as well. It is the job of new releases to be
backwards compatible, not old releases to be forward compatible.
While I agree not to clutter PHP5 too much I can see the point in
(Wietse Venema) wrote:
! zend_uchar is_ref:7;
! zend_uchar taint_flag:1;
Beginning of this year I was actually making tests with something like
that but I used
zend_uchar is_ref:1;
zend_uchar flags:7;
to be able to support multiple taint types (HTML and DB where
101 - 200 of 568 matches
Mail list logo