Larry Garfield wrote:
On Monday 18 February 2008, Richard Lynch wrote:
Why not just allow 'include' here instead?
Because include requires the code in question to live in another file, which
I
don't always want.
I'm with Richard Lynch here: Simply allow inclusion. No new language
Gregory Beaver wrote:
Here is a slightly clearer syntax for trait instantiation and for
aliasing/removing method names from traits:
?php
trait foo
...
class B
{
trait foo {unset bing, bar as bing};
trait bar;
}
I like the approach to reuse identifiers (trait both in
Gregory Beaver schrieb:
Christian Schneider wrote:
Another detail: The implementation of the parser changes should still
allow a class or function called trait, i.e. trait should only be a
keyword at specific positions in the source to avoid unneccesary BC
breaks. The current patch has this BC
Richard Quadling schrieb:
On 21/02/2008, Richard Lynch [EMAIL PROTECTED] wrote:
In fact, new users are often confused because the CAN'T do an include
in the middle of a class -- A rule which, to some, seems arbitrary and
illogical.
And once they understand (if they do) why they cannot use
Marcus Boerger wrote:
you still cannot ignore basic inheritance or reuse rules. Protocols
have to be respected - E_FATAL, fix your code.
I have several comments (plus patches) to this:
1) The current checks are IMHO too strict regarding default values for
parameters: An inheriting class can
Hi all,
playing around with PHP 6 I noticed the following BC issue:
floatval(4.2foo) gives an E_NOTICE A non well formed numeric value
encountered. The type casting (float)4.2foo still works as before.
The change was introduced with the conversion of floatval() to
zend_parse_parameters with
Justin Martin wrote:
headers generated by an HTTP request. The primary parameter to this,
string $url, is provided unencoded. Due to this, any request with
special characters (i.e. a space), will return 400 BAD REQUEST. My
Garbage in, garbage out. It is up to you to provide it with a valid URL
Dmitry Stogov wrote:
Drupal 20% faster
Qdig 2% faster
typo3 30% faster
wordpress 15% faster
xoops 10% faster
Out of curiosity: I assume this is without an opcode cache?
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
David Zülke wrote:
of course. how can you measure scanner performance with an opcode cache
on :p
That's what I thought. It also means my initial excitement is gone as we
(as anyone running anything but a personal home page) are using opcode
caches anyway. I basically just wanted it to be
Playing around with PHP 6 I noticed that some functions start to
complain about conversion of null values to strings:
php -d error_reporting=65535 -r 'var_dump(urldecode(null));'
Warning: urldecode() expects parameter 1 to be strictly a binary string,
null given in Command line code on line 1
Pierre Joye wrote:
On Tue, Mar 4, 2008 at 3:17 PM, Christian Schneider
[EMAIL PROTECTED] wrote:
playing around with PHP 6 I noticed the following BC issue:
floatval(4.2foo) gives an E_NOTICE A non well formed numeric value
encountered. The type casting (float)4.2foo still works as before
Am 26.03.2008 um 20:48 schrieb Stanislav Malyshev:
Which # is it?
Re-opened. http://bugs.php.net/bug.php?id=44533
So it's just gives additional notice? That's a bit strange since
intval doesn't, and neither does (float). I see no reason for
floatval() to be different from others.
I
Stanislav Malyshev wrote:
I'm not sure I understand - how array_reduce is related to having type
hints? You could make array_reduce to do additional things, but that
doesn't require introducing strong typing into php.
The relation between array_reduce and scalar type hints is that API
start to
Richard Quadling schrieb:
Type juggling just doesn't seem to fit well with me.
You seem to live in a completely different PHP world. Because in our
case we use (yes, knowingly use) the PHP type juggling and it safes us
lots of manual type conversions.
We get input from all different
I attached a patch and a phpt-file for a small patch to array_reduce
to allow any type of $initial value. This patch is for HEAD but could
easily be applied/ported to 5.3.
- Chris
Index: ext/standard/array.c
===
RCS file:
Actually nothing could support my point about giving the wrong signals
better than these two postings: They are IMHO on the wrong track on how
to make an interface better.
Krister Karlström wrote:
This is maybe getting a bit out of topic now, but what about
function/method overloading using
Derick Rethans wrote:
I've been working on some code, while developing on PHP 5.3. The code
resembles the following structure:
?php
interface ezcSearchQuery
{
public function limit( $limit, $offset = '' );
}
class ezcSearchFindQuerySolr implements ezcSearchQuery
{
public
Stefan Walk schrieb:
Richard Quadling schrieb:
On 12/04/2008, Rasmus Lerdorf [EMAIL PROTECTED] wrote:
There is no bug here. Please read:
http://docs.sun.com/source/806-3568/ncg_goldberg.html
-Rasmus
So, would I be right in thinking that the only time type-juggling is
100% successful is
Chris Stockton schrieb:
Why on earth would you have int, string, resource, etc return type hints
and then turn around and suggest for parameter hinting just add a scalar
type? That makes no sense and is so inconsistent.
static int function retarded(scalar $value) {
return (int) $value; //
Felipe Pena wrote:
For parameter type hints, i have completed the actual implementation
with the leftover php types:
- string (binary string and unicode)
- integer (accepting numeric string too)
- double (accepting numeric string too)
- boolean ('0', '1', true, false)
- resource
- object
Arvids Godjuks wrote:
So full syntax will be like this
function (integer) test(integer $value) { ... }
I guess you are right: int and integer seem to be aliase and both check
for int *or* numeric strings, not the type int.
It is also not clear if (string) accepts ints/floats which are often
Felipe Pena wrote:
Well, thinking better about the behavior of type hinting, i decided to
change the proposal for strict type. I.e. don't accept numeric string
as an intenger, etc.
While it is now consistent with is_int() it means we end up with strict
but also stupid interfaces and hence lots
Arvids Godjuks wrote:
Most normal developers are for years with utf-8 for now and even wouldn't
notice it.
Sorry to destroy your pipe dream but that's just not true.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Arvids Godjuks wrote:
Well, at least in my country i haven't saw any normal programmer not using
unicode :)
meta-posting
I guess that was meant to be an ironic comment but I think we should
improve the signal-to-noise ration on internals again.
/meta-posting
- Chris
--
PHP Internals - PHP
Marcus Boerger wrote:
unset($o_Foo-bar);
echo $o_Foo-bar;
?
outputs ...
Notice: Undefined property: foo::$bar in C:\- on line 13
At this point you found an error. Because this allows unset() to modify an
instance in a way that it nolonger adheres to its class that means at this
point
Am 14.05.2008 um 02:06 schrieb Marcus Boerger:
So you are saying that
$o_Foo-bar = array(42);
is ok when the class expects a string but
unset($o_Foo-bar);
or (as as slight variation)
$o-Foo-bar = null;
is not?
I Do not get the connection here? And since when can we
Richard Quadling wrote:
_IF_ the property was defined in an interface, should unset be
allowed to remove the property?
a) Interfaces do not define attributes, they define a set of methods.
b) If the above would be changed I still want to be able to shoot myself
in the foot if I *explicitely*
Hi Marcus,
Am 18.05.2008 um 13:20 schrieb Marcus Boerger:
Not allowing unset() is the bug. Having unset delete the property
would be
the error. As long as the property still exists with value NULL all is
fine.
I think unset($foo-bar) should unset while $foo-bar = null should
set to null
Hi Marcus,
Am 18.05.2008 um 18:41 schrieb Marcus Boerger:
Just to make this clear once and for ever. If unset() deletes the
property then:
a) it would break inheritance
b) accomplish nothing, as the next access would simply recreate it
Ok, you don't want this thread to die, so here we go:
Richard Quadling wrote:
(Not E_STRICT) If error_reporting does not include E_STRICT, then
unset()'ting properties defined in interfaces is allowed and operates
exactly as it does on normal variables and for properties defined in
classes. Whilst this may break the contract, this is what
Richard Quadling wrote:
In trying to understand the proposal of allowing properties via
interfaces from your (Chris') point of view, what benefit do we get?
I don't use interfaces at all so I don't have a strong opinion about the
benefits or drawbacks of adding properties really but ...
Evan Priestley wrote:
support more versions of PHP with your project. It's also
straightforward to write a script that uses the tokenizer to safely and
unambiguously remove trailing commas (I'd be happy to furnish such a
The script convertsyntax.php at http://cschneid.com/php/ already
provides
Richard Quadling wrote:
Actually, would allowing PHP to skip defaulted parameters be a better
facility to add?
function foo($opt1 = Null, $opt2 = Null){}
foo(,True);
I agree that it would be ugly but possibly useful. OTOH I think it's
better to switch to named parameters in such a case
Matt Wilmas wrote:
array_replace() is like the + operator applied to arrays, except that it
WILL overwrite (replace) existing entries.
Excuse my ignorance but what's the difference between
$array = array_replace($array1, $array2);
and
$array = $array2 + $array1;
apart from
Am 10.04.2008 um 14:02 schrieb Marcus Boerger:
looks good to me. Sidenote: If you cvs add the new test and then do
cvs
di -N, then you get the new files and the stuff you changed in one
diff.
If you do not have access then a) you need to do the cvs add step
manually by editing the
Jani Taskinen wrote:
There are some bugs that have to be fixed before any actual release can
be even dreamed of:
http://bugs.php.net/search.php?cmd=displaystatus=Critical
Note that 2 of those even have patches attached to fix them..
I had a quick look at bug
Arnaud Le Blanc wrote:
The following may (no MacOS X to test) fix the problem by returning 0 from
zend_stream_fsize() when the file descriptor is not a regular file:
http://arnaud.lb.s3.amazonaws.com/45928.patch
Your patch:
+#ifdef S_ISREG
+ if (!S_ISREG(buf.st_mode)) {
+
Am 10.09.2008 um 10:52 schrieb Tullio Andreatta ML:
fstat on a open-ed fd can't stat a symbolic link, since
open(symlink) returns a file descriptor of the target file, or -1
if it's a dangling link ...
Yes, that's right. So Arnaud's patch at http://arnaud.lb.s3.amazonaws.com/45928.patch
+1 for option 3 too (http://wiki.php.net/rfc/namespaceissues)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Jani Taskinen wrote:
http://bugs.php.net/bug.php?id=44938edit=1
Marked critical but propably isn't. Also depatable whether it's a PHP
bug at all..
Probably the library exhausting memory using alloca I'd say.
I whipped together a little patch against HEAD which restricts the
length of a text
Lukas Kahwe Smith wrote:
one could also do
1) ns
2) global
3) autoload
I'm in favour of this (if it avoids performance problems) as I don't see
a problem with giving global priority over autoload.
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Igor Feghali wrote:
// NOTE: leaving the callback function empty is not desired. 0 and 0.0
should not be skipped in the implode array !
array_filter($arr, 'myfunc');
implode('foo', $arr);
against:
implode('foo', $arr, true);
implode('foo', array_filter($arr, 'myfunc'));
Simple enough
jay wrote:
okey. another syntax:
myfunc($('key1'='val1', 'key2'='val2', ...));
This has been discussed and rejected several times.
If you still want to be able to use this syntax you can use my patch at
http://cschneid.com/php/
including a script to convert from and to this syntax.
We
Jay I. wrote:
interesting idea, thanks. but unfortunately it won't help me as i really
need to pass arrays as a single argument like this:
my_func($param_1,$param_2,array(...));
You can do that. All parameters in a row with = will be merged to one
array.
You could call
myfunc($a,
Lukas Kahwe Smith wrote:
On 21.01.2009, at 12:00, Karsten Dambekalns wrote:
On 21.01.2009 11:44 Uhr, Kenan R Sulayman wrote:
I did propose the function because the construction in user-land is
quite
expensive;
Reflection is expensive, indeed. The way we solved it for FLOW3 is to
create a
Nathan Rixham wrote:
seems to me that many of the new requests coming in, including my own
stupid ones are because people want to build fast decent orm's in php -
Having built an ORM system myself I can say that you don't need
Reflection (or even other fancy features not yet in PHP) for this.
Lukas Kahwe Smith wrote:
On 24.01.2009, at 00:49, Andrei Zmievski wrote:
Hannes Magnusson wrote:
I don't think we have to treat our users like a total fcking idiots.
If anyone thinks using SPL or PHP as their root namespace is a
good idea they deserve to be kicked in the nuts.
And who's
Eric Stewart wrote:
A new RFC for PHP's proposed INI files have been added to the wiki. Below is
a direct link to the page.
http://wiki.php.net/rfc/newinis
Good work IMHO.
Similar to what Karsten Dambekalns wrote I think we should only have a
difference between devel and production for
Michael Shadle wrote:
On Fri, May 15, 2009 at 1:25 PM, Lukas Kahwe Smith m...@pooteeweet.org
wrote:
Confusing new code is totally different from breaking existing code.
True but aren't some changes in 6.0 at least (and possibly 5.3) going
to require code changes? Or is it still going to
Lukas Kahwe Smith wrote:
The PHP Development Team would like to announce the immediate release of
PHP 5.3.0. This release is a major improvement in the 5.X series, which
Congratulations to everybody!
One quick question: What is the situation with opcode caches, are APC
and/or EAccelerator
Greg Beaver wrote:
I would like to ask all developers to voice their opinions of whether it
makes sense to add this to 5.3 or to throw it away (either one is fine
btw). To keep the process simple flamewar free, please restrict
yourself to +/- (1/0), next week monday I'll run a tally of the
Stan Vassilev wrote:
+1 if the object type hint is change to use T_CLASS so we don't break
every external package using Object as a base class.
http://www.google.com/codesearch?as_q=class\s%2BobjectbtnG=Search+Codehl=enas_lang=phpas_license_restrict=ias_license=as_package=as_filename=as_case=
Zeev Suraski wrote:
We need to go back to the fundamentals - and look for use cases where
strict typing would be substantially superior to weak typing.
I whole-heartedly agree. I can see some benefits of having weak typing
(even though I'm not desperate for it) and think it would better fit PHP
Robert Lemke wrote:
thanks a lot for your outstanding work!
Yes, I second that. Thanks, Lukas!
And to Johannes: Keep up the good work!
Cheers,
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Richard Lynch wrote:
I think anybody who is coding with strict/weak/contract
type-enforcement/casting is going to understand
try/catch/Exceptions...
I'm not going to start an pro/contra Exceptions rant but *please* keep
Exceptions out of the core language itself, that's a line we should not
Derick Rethans wrote:
On Mon, 24 Aug 2009, Rasmus Lerdorf wrote:
Lukas, the problem is that all messages, E_STRICT, E_DEPRECATED,
E_NOTICE, whatever, all cause a performance hit even if the
error_reporting level is such that they will never show up anywhere.
That's what this patch is trying
Mark Krenz wrote:
But I'm willing to bet that the majority of people are using ereg, not
PCRE. I've known about PCRE in PHP for a while now, but I continue to
use ereg because I thought it had better support in PHP and that it was
the more official function. Guess I was wrong. I'm sure I'm
Lukas Kahwe Smith wrote:
I have written an RFC for a more efficient solution to get rid of the
common fopen() hack inside autoloaders:
if ($fp = @fopen($file, 'r', true)) {
fclose($fp);
include $file;
}
Here is the gist of the proposal:
In order to solve the above issues this RFC
Hans-Peter Oeri wrote:
The problem for me as a php end-user currently is, that no coherent
error behaviour in php exists. Core functions only issue errors, intl
To be honest I prefer an inconsistent but stable error mechanism.
Allowing to change the error behaviour (e.g. something as extreme as
Alexey Zakhlestin wrote:
Would be nice if something like this worked too:
(new Class())-method();
If you *really* want to do this you can use a factory method:
Class::create()-method();
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Andi Gutmans wrote:
So what I'm thinking of is:
array(1, 2, 3) == [1, 2, 3]
I like this syntax, more conscise but still clear (and well established
in other languages by now).
Two more thoughts (but please don't kill Andi's proposal because of it,
rather dismiss my comments instead ;-)):
Hannes Magnusson wrote:
typeHinted([1 = [1 = []]]); // array(1 = array(1 = array()));
IMHO the common case would benefit and your pathological example is
unreadable both ways. Personally I'd reformat it to
typeHinted([
1 = [
1 = []
]
]);
resp.
Richard Lynch wrote:
So now we have an invisible operator with a magical symbol '[' which
*sometimes* means create an array, but *sometimes* means to
de-construct an array into individual variables?
The distinction you are making is from an implementation point of view.
From a language users
Lukas Kahwe Smith wrote:
Named parameters is not just syntax sugar, as they would make it
possible to get compiler errors and phpoc support automatically over
having to implement some array based solution to trigger errors and some
Not 'our' way of named parameters where the main feature is
Richard Quadling wrote:
Argh! Reading such a line, I think of named parameters, not an array.
That's exactly what we are emulating this way ;-)
I agree with Francois here. Other than looking STRONLY like named
parameters, surely there is a flaw if a declaration is ...
function
Alain Williams wrote:
Anyway: it makes php look like perl -- and that would never do :-)
Can we please stop that FUD? (even if it is meant as a joke)
... if at all then you might say it looks like Javascript, Python or
Ruby. Perl uses an ugly mix of () and [] to emulate multi-dimensional
arrays
Guilherme Blanco wrote:
Brian,I am sorry about the message indentation... Seems PHP-Internals
list does not like M$ Live(r) Mail!
Please use plain text mail as your messages are a PITA to read, thanks.
you can see, the only change needed is in a throw-able error (Undefined
variable), which
Jim Wilson wrote:
1) Is there a way to inject a method into a Class such that future
instantiations of that Class will have the method? For example:
2) Is there a way to change a method which already exists, as in by
overwriting it with a new function? I'm looking to do the equivalent of
Richard Lynch wrote:
I'd be perfectly happy if PHP's anonymous functions had the nice
syntax and no funky weird stuff about closure, a la
eval/create_function, personally.
While the discussion about closures and how to emulate them was
interesting I think Richard hits the nail on the head.
Michael Walter wrote:
Right. But then those people add 2 + 2 and get frustrated because they
can't do the obvious ;)
I find it all but obvious to being able to use non-local, non-global
variables in PHP. It's one of the main PHP points IMHO that a variables
is either local or explicitely
Michael Walter wrote:
I find it all but obvious to being able to use non-local, non-global
variables in PHP. It's one of the main PHP points IMHO that a variables
is either local or explicitely accessed through $_GLOBALS (or super
globals). It gives me a warm and fuzzy feeling that I know
Michael Walter wrote:
A simple real-life example is:
function pick($member)
{
return create_function('$x', 'return $x-'.$member.';');
}
which could be used e.g. in
array_map(pick('age'), $people).
Arguably, in this case you could as well write:
array_map(function($p) {return
Hi there,
looking around quickly I couldn't find any documentation on the
following change:
$a = foo; echo \{$a};
PHP 4.4.4: {foo}
PHP 5.2.1: \{foo}
I didn't check which exact version introduced this change. Some
third-party code used this obscure construct and failed when migrating
from
Tomas Kuliavas wrote:
It was changed in 5.1.0-5.1.1 versions.
According to PHP Manual (http://www.php.net/language.types.string) curly
brackets are not escaped with backslash. Escape worked in older PHP
versions. It does not work in 5.1.1+.
http://bugs.php.net/31341
http://bugs.php.net/35411
Fernando chucre wrote:
I build a patch for wrapper php fopen. In this patch I create a way for
the script access the filedescriptos opened by process. Ex:
I assume this is non-portable anyway so you could also simply use
something like /dev/fd/7 instead of php://fd/7 if you're on Linux or
Hannes Magnusson wrote:
7. add E_STRICT to E_ALL DONE (dmitry)
My dictionary says that all means *all*, not all except this and
this and sometimes not that.
E_ALL should have been called E_RECOMMENDED or E_DEFAULT to avoid this
confusion but in reality changing E_ALL to include everything
Hi all,
I ran into the following problem I would like to get an opinion on: We
noticed that our website returns a HTTP/1.1 chunked response even when
the request was a HTTP/1.0 request (e.g. php file_get_contents).
What happens:
- Wordpress (wrongly) set the result code with a hardcoded
Rasmus Lerdorf wrote:
Replying to a 1.0 request with a 1.1 response is perfectly fine.
It is the default for a fresh Apache install on a request for a
simple static file, for example.
This seems bogus to me.
Quoting from the very last line of the HTTP RFC 3.6 Transfer Codings:
Christian Schneider wrote:
version for which the server is at least conditionally compliant, and
whose major version is less than or equal to the one received in the
request.
Oops, missed the major version part there. Sorry for that, should read
things more carefully, especially at 1:30am
Rasmus Lerdorf wrote:
Go read the archives. And note that I only said it was fine to respond
with a 1.1 reply, that doesn't mean it is fine to send an encoding the
client doesn't support.
That's why I think PHP shouldn't mess with the proto_num field or
otherwise upgrade the HTTP version of
Uwe Schindler wrote:
* Some scripts use header('HTTP/1.0 301 Moved Permanently'). Problem here:
You must supply a HTTP version (this seems to be a problem in Apache), and
This is not necessarily a problem with Apache, it is just a problem in
the current implementation as far as I can tell. If
Stut wrote:
It doesn't matter where the session ID comes from, the basic point is
that you have to trust it or implement some experience-degrading
mechanism like client certificates, and even there there are few
guarantees.
You want more info to be checked? Simply add a variable containing
Wez Furlong wrote:
As Rasmus said, it's a job for someone to sit down with a copy of the
repository, cvs2svn, a lot of time, and a lot of patience, to make the
migration work... but we're not stopping anyone from volunteering :)
I converted our company's CVS to SVN a while ago and might be
Stefan Walk wrote:
At the moment, SVN is a pain in the ass when it comes to merging, but
they claim that it's fixed in 1.5...
svnmerge.py: http://www.orcaware.com/svn/wiki/Svnmerge.py
can help quite a lot as it maintains merges. And as it stores the merge
information in SVN properties I'm
Daniel Penning wrote:
Checking if the reference is equal and then doing the member-by-member
comparison if they differ would prevent too deep recursion in most cases.
That would solve this particular case (and might be worth doing for
performance reasons anyway I'd say) but won't solve the
Derick Rethans wrote:
Well, our implementation is not namespaces, packet doesn't have any
meaning in this case, so perhaps you have a better suggestion than
package then?
Just a quick reminder to everybody here: The feature is important, the
name (package or namespace) is less so. Even if
Stanislav Malyshev wrote:
I would consider making internal class names illegal
in namespaces. this would be consistent simple and clear.
It's one of the options, but I'm not sure it's the best one. Opinions
welcome.
I don't think that's a good solution because that kind of defeats the
Marcus Boerger wrote:
If you have such a patch you should definitively post it here so that we
can hve a look. Most interesting to us is however the oerformance impact. As
that was the main reason to go any further than adding return type hints.
Am I the only here who thinks that performance
Hans Moog wrote:
You are missing something. Using this new feature would be
voluntarily (it is optional like type hints are already).
Thanks for bringing that up right after I told you that I won't accept
this argument ;-)
If you want to code the old way and you don't want to force coders
Hans Moog wrote:
When it would be:
==
function xpath(DomDocument $arg) {
return new DomXPath($arg);
}
function xpath(XmlTree $arg) {
return new DomXPath($this-loadXML($arg-getSource(;
}
function xpath(string $arg) {
return new DomXPath($this-loadXML($arg));
}
==
Hans Moog wrote:
And if you have more than one parameter you will name it
methodFromStringIntegerSampleClassBoolean ?!?
No, I would rethink my interface.
And how would you do the same for constructors ?!? Create a
initWithStringIntegerSampleClassBoolean method which has to be called
after
news.php.net wrote:
I might have a define(DEBUG,$_SERVER[REMOTE_ADDR]==myip); included -
on not
Just make sure you always set DEBUG, shouldn't be too hard if your code
has any structure ;-)
- Chris
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
First of all: I've been playing around with it and it looks great!
Some comments:
1) I added taint support to func_get_args() and func_get_arg(), a patch
is attached.
2) Maybe the functions should be renamed to taint_xxx (e.g. taint_set,
taint_clear, taint_check or the like) to reside in their
David Zülke wrote:
An untaint() approach - all for it (yes, the noobs that don't give a
damn are going to use it because it just works, but no, that shouldn't
Most people here seem to agree that it would be valuable tool for
themselves to be able to taint/untaint data. Wietse's approach is very
Am 21.10.2012 um 13:33 schrieb Nikita Nefedov inefe...@gmail.com:
No, this is useful in any OOP-language where there is such thing as type, and
people need to validate types.
I question the need to validate types part. I'd say you're better off using a
completely different language if you
Am 22.10.2012 um 21:44 schrieb Anthony Ferrara ircmax...@gmail.com:
This is not about turning PHP into Java. Can we get over that old rhetoric
already? Instead of bashing proposals like this, can we discuss them,
instead of this hatred for all things strict?
With that aside, I have mixed
Am 13.03.2012, 02:34 Uhr, schrieb Rasmus Lerdorf ras...@lerdorf.com:
On 03/12/2012 05:52 PM, Yasuo Ohgaki wrote:
I always set all parameters for htmlentities/htmlspecialchars, therefore
I haven't noticed this was changed from 5.3. They may be migrating from
5.2 or older. (RHEL5 uses 5.1)
No,
Am 03.07.2012 um 18:21 schrieb Anthony Ferrara:
know you didn't like PASSWORD_MOST_SECURE. So what about keeping
PASSWORD_DEFAULT as a moving target, documented, and just making the
second parameter (algo) to password_hash required? That way users
To be honest I'm not sure of the benefit
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
1 - 100 of 568 matches
Mail list logo
