7;t compile PHP myself, I
use a debian file from dotdeb.org, but the phpinfo() shows 5.0.4, so I
assume it is installed relatively correctly.
Could this be a bad install somehow, or is it possible that the bugfix is
missing?
Ron Korving
--
PHP Internals - PHP Runtime Development Mailing List
To uns
I couldn't agree with you more. This would be a great new feature for PHP
5.1 (which it probably won't be), or 5.2.
Ron
"Steven Wittens" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Hi,
>
> As a PHP user I'm sadly confronted daily with PHP's lack of proper
> Unicode support. PH
"Magnus Määttä" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> What about ifsetor for 5.1 ?
Would anybody be interested in a parameter for ifsetor() that would treat
isset() as !empty() or an alternative function that achieves this? I know
I'd love to see that. I use empty() a lot
I must say, I like the coalesce() idea a lot. It gives more flexibility over
ifsetor() which sounds to me like it only handles 1 variable that is or
isn't set. coalesce() would handle any number of variables.
Here's something else to consider though:
Would anybody be interested in a parameter for
The problem with your example of firstNotEmpty() would be that if a variable
is not set, I'll get a notice, which I don't want. So it's really no
different from an isset() check. You want to be able to apply it to an
variable that is not yet set.
Ron
""Sara Golemon"" <[EMAIL PROTECTED]> wrote in
If it were possible at all to make a function accept unset variables without
generating a notice, I think ifsetor() shouldn't even be implemented. People
could then have the freedom to create such functions themselves. But
unfortunately, it doesn't seem to be possible, unless you'd suppress every
f
t; like a sensible goal to me. As nice as it is to be able to roll your
> NB> own, code sharing is facilitated when we include de facto behaviors.
> NB> The single implementation close to the metal would also help with
> NB> speed and code verifiability.
>
> NB>
But how about this..:
Let's not implement functions that do what you want to achieve, but extend
PHP in whatever way necessary that would enable you to write such a function
yourself?
Say for example that prepending @ to function parameters would make it
possible to call the function with an unse
No, ifsetor() is not possible in user land, because it generates notices,
and a php core function ifsetor() would not generate notices. That's really
the way it has to be.
Ron
"Sven Fuchs" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Why isn't is possible in userland? Is there a
Hmm, you're right.. so the reference "&" already takes care of this...
Well, then I don't see the point of the whole ifsetor() discussions...
people can implement this themselves.
Ron
"Sebastian Mendel" <[EMAIL PROTECTED]> wrote in message
ne
Hi Zeev,
You're absolutely right.. How awful of me that I didn't see this coming.
Honestly, what's the point of having an ifsetor() in PHP, when people can
obviously write it themselves? Everybody wants a slighty different
implementation of an ifsetor(), ifnotemptyor(), coalesce(), etc... Why are
Personally, I doubt this is a problem.. I mean, how many ifsetor() variables
are we talking here? You call the function, so therefor the variable could
be set, otherwise you wouldn't be checking for it. In the case it was set,
it would've been in the symbol table anyway.
Ron
"Sven Fuchs" <[EMAIL
Personally, I doubt this is a problem.. I mean, how many ifsetor() variables
are we talking here? You call the function, so therefor the variable could
be set, otherwise you wouldn't be checking for it. In the case it was set,
it would've been in the symbol table anyway.
Ron
"Sven Fuchs" <[EMAIL
There is one case though, which can still not be implemented (probably?) by
users, and that's a coalesce function, since that would require fetching
values by using func_get_args(), which doesn't return references.
So the only way I could imagine implementing such coalesce() function would
be like
Quote from http://code.google.com
We're Expanding the Summer of Code... - 17/Jun/2005
After spot reviewing the applications we've received for the Summer of Code,
we were struck with their high quality. As a result, we were able to
increase the funds available to support 400 students, double our o
E_STRICT would be a nice place to leave a warning, but of course, the naive
programmers don't use E_STRICT, so what's the point in that? Personally, I
think include is just fine the way it is. What I could imagine though, is
that the include() function would be enhanced with parameters to
allow/dis
> If the very first thing you have to do with a language feature is make
> sure that it doesn't function as designed (which is to execute hostile
> content with local privileges), then clearly the design of that
> feature is wrong.
Or the default value of the configuration setting has been a bad c
> >Lastly, there IS a note in the announcement stating that the major
version
> >increase is due to a non-BC change, I don't see what everyone is
> >complaining about. Perhaps you should request that your users read what
> >they're downloading before they download it.
>
> Wrong, read the announceme
ews:[EMAIL PROTECTED]
> On Sat, 16 Jul 2005, Ron Korving wrote:
>
> > It doesn't matter how wrong the programmers were by abusing PHP in this
way.
> > You have to feel sympathy for the fact that these people will be
upgrading
> > their servers only to find out their code
Hi,
Will there be a gzdecode() function in the future? I really need it, and the
function provided by Aaron G. on
http://nl2.php.net/manual/en/function.gzencode.php#44470 doesn't always seem
to work ("data error" warning on a newly gzipped file). I tried to go
through the ext/zlib code, trying to
When I receive a warning that an XSD file could not be opened, it urlencodes
the filepath. That doesn't make sense to me...
Example:
Warning: I/O warning : failed to load external entity
"/var/www/my%20test%20schema.xsd" in /var/www/test.php on line 10
Is this a bug?
Ron
PS: Weird thing is that
s is probably a bug.
> I don't know if it easy fixable.
> You can post it into bugs.php.net, and I'll look into it (when I'll have
> time for it).
>
> Thanks. Dmitry.
>
> > -Original Message-
> > From: Ron Korving [mailto:[EMAIL PROTECTED]
>
external entitity. Either surpress the errors when calling
> whichever function or you can use the new error handling for xml in 5.1
> which wont issue/display errors directly but any can be retrieved after
> the function call.
>
> Rob
>
> Ron Korving wrote:
>
> >Yes, sp
the information that says the actual XSD-file is missing. Again, for me
personally, this requires no fix.
Ron
"Christian Stocker" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
>
>
> On 2.8.2005 10:16 Uhr, Ron Korving wrote:
> > Shouldn't PHP sup
Hi,
Wouldn't it be a good feature to have users create their own superglobals? I
think it would be good for at least two reasons (rather similar though):
- Application settings can be stored in such a global, so that objects can
use them without needing the information passed to functions or usin
Hi,
This may be an odd suggestion/request, and nothing in the line of what's
currently hot around here (PHP 5.1 that is), but I'm making it anyway:
The current behavior of socket_recvfrom() (/etc/sockets/socket.h) on a
connection error, is that it frees the buffer (recv_buf), throws an error
and
I've noticed that in a script of mine, memory consumption can explode quite
drastically when Exceptions are thrown, opposed to very normal memory
consumption when exceptions are not thrown.
This is the idea:
process();
}
catch (Exception $e)
{
$errors[] = $e->getMessage();
}
}
?>
Whe
It is very likely that this has something to do with DOM. It's a huge piece
of code though, making it hard to test where the problem really lies.
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> I've noticed that in a script
in the foreach(). It
seems the $largeResultSet is not freed in this case. Using the foreach by
reference or not (&$item or $item) does not make a difference.
Ron
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> It is very likely that
Nonetheless, Rasmus, isn't it something to work on? Like Steve said, #1 and
#2 can be accomplished, and that would at least be a good start. You are
right about the libraries, but in time, even these may become thread safe
(of course, likely not by anyone from the PHP-community). Why is this
thread
e
> problem? Thanks.
>
> At 05:27 PM 8/9/2005 +0200, Ron Korving wrote:
> >The problem occurs in this particular situation:
> >
> >public function process($data)
> >{
> > $largeResultSet = $this->xmlParser->parseString($data);
> >
> > fo
You're right, using that file to create a big piece of data was just for
demonstration purposes. In my personal case it's XML parsing. The way I read
what you just said is that this is behavior by design. But if I don't throw
Exceptions, memory usage stays constant. Throwing and catching these
exce
This looks very promising, I'm impressed by the work you guys have done (big
thumbs up).
There are a few issues/questions I have after reading your document:
"Therefore, command such as 'print' and 'echo' automatically convert their
arguments to the specified encoding. No automatic output encodi
icht
news:[EMAIL PROTECTED]
> I have opened the bug #34065, but it is very hard to fix it.
>
> Thanks. Dmitry.
>
> > -Original Message-
> > From: Ron Korving [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, August 10, 2005 1:55 PM
> > To: internals@lists.
ans" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> On Wed, 10 Aug 2005, Ron Korving wrote:
>
> > Perhaps it would require an revised garbage collection mechanism? If
that's
> > the case and you think it's worth investing time in, I think it w
"Derick Rethans" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> On Wed, 10 Aug 2005, Ron Korving wrote:
>
> > My situation is parsing a number of XML-reports. If parsing goes wrong
in
> > any way (XML parsing fails, XML validation fails, databa
cribe is hard to detect. I
> will however put it on our TODO list because this case could possibly be
> improved on.
>
> Andi
>
> At 11:54 AM 8/10/2005 +0200, Ron Korving wrote:
> >You're right, using that file to create a big piece of data was just for
> >demonstr
pply if you use the reference operator?
>
> foreach ($data as &$lines) { ..
>
> ?
>
> - Markus
>
> Wez Furlong wrote:
> > foreach() 'copies' $data, and it's the copy that isn't going away.
> >
> > --Wez.
> >
> > On 8
Exactly. That's how I understood it too: "Ah, the __toString behavior". I'm
very glad this is not the case.
Ron
"George Schlossnagle" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
>
> On Aug 10, 2005, at 10:30 AM, Rasmus Lerdorf wrote:
>
> > Yeah, print/echo was just a way of des
I firmly believe though, that all outputting functions should act the same.
It's the same problem otherwise as with __toString(). I would use __toString
if it wasn't just restricted to echo and print, but right now it's pretty
useless to me. I hope that behavior can change in a major version update
Sounds absolutely great :)
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Ron,
>
> i had a chat with Andi about __toString() and i hope that he finally
> undestood why a lot of ppl wanted it right from the beginning. To me the
> current situation is si
Now I'm not the person with the kind of karma that should make you guys
listen, but in case you are interested, I'll just add my 2 cents
> 1. Remove register_globals completely
+1
> 2. Remove magic_quotes_*
+1000
> 6. Remove some stuff that has been marked deprecated since PHP 3/4
+1
> A cou
Oh, and I almost forgot one wishlist item I've had on my list for a long
time (I hope you guys have an open mind)
How about doubling integer precision to 64 bits and float/double precision
to 128 bits? It's in line with 64 bit CPU capabilities, and personally, I
wouldn't mind it a bit if i
What's bad about using [] for strings? I think people who come from a
C-background (like myself) really like that syntax. I'd prefer it to stay
the way it is.
Ron
"Andrei Zmievski" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> We did, but we never arrived at consensus. I don't rea
Perhaps the named parameters could even be constant-like?
How would this syntax be?
foo(id => 42, name => "foo");
Ron
"Matthew Weier O'Phinney" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> * Christian Schneider <[EMAIL PROTECTED]> :
> > 9. Named parameters. Preferred way would
"Christian Schneider" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> foo(id: 64738, name: "foo");
Oh, I love that syntax ;)
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
But why doesn't work? If that'd work, I just might start using
Ron
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Paul Reinheimer wrote:
> > My prefrerence would be for the interpreter to look for " > short tags is enabled (that was brace, question mark, white sp
Can't help it... ;) By the way, I thought all programmers were lazy to some
extent?
Seriously though, I think it would be nice and consistent if it would work.
I just really like the short wrote in message
news:[EMAIL PROTECTED]
Why do you find the need to be lazy and use lol j/k
i always use
It's unclear to me what the position of the big kahuna's is on the following
issues, but I hope they can become a reality in PHP6:
1) named parameters.
in user functions, but also in core functions:
$result = in_array(needle: "foo", haystack: $array);
2) error reporting using exceptions.
I would
I very much like your idea and syntax. I come from a Delphi background (when
it comes to properties) and I must say I like your solution. It's easy and
effective. Yes, it can be done with __set() and __get(), but it sure is
uglier when you have a wide and constant range of properties.
+1 (with 0 k
>> like a much better idea to me then trying to expand upon it.
> >>
> >> Cheers,
> >>
> >> John
> >>
> >> On Wed, 2005-08-31 at 15:23 +0200, Ron Korving wrote:
> >> > Can't help it... ;) By the way, I thought a
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Ron,
>
> Wednesday, August 31, 2005, 3:37:51 PM, you wrote:
>
> > 2) error reporting using exceptions.
> > I would like it if I could catch PHP-errors and take appropriate action
> > (such as logging it to a datab
Hi,
> >> > 2) error reporting using exceptions.
> >> > I would like it if I could catch PHP-errors and take appropriate
action
> >> > (such as logging it to a database or whatever).
> >>
> >> You can already do that with 5.1 by adding three lines of code.
>
> > Sounds awesome.. is this documented
I agree. I've always found it weird that no notice is thrown in this
situation. Still I discourage people to code like this.
Ron
"Etienne Kneuss" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hi,
>
> As you surely know, arrays are often badly initialized:
>
> // $array is undefi
Wouldn't it be more practical to implement these as stream filters?
Ron
"Wojtek Meler" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> I've patched original crc32 PHP function to allow incremental crc32
> counting.
> It touches only a few lines of original code.
> New crc32 funct
in bericht
news:[EMAIL PROTECTED]
> Ron Korving wrote:
> > Wouldn't it be more practical to implement these as stream filters?
>
> Sure - I was not aware PHP5 streams - I'm still using PHP4
> string.base64 is good choice. But I'm not sure if crc fit to streams.
> You
Hi,
For performance' sake, I have to know if this is true:
Is it the case that when I do this:
array(0,1,2), "two" => array(4,5,6));
$one = $array["one"];
?>
That $one is not a copy, but a reference to $array["one"] and will only
become a copy when I alter the contents of $one? I know this i
> Yes it is legal because it worked
That's nonsense. Even in the C-language certain things have worked in the
past because of compiler bugs. Newer GCC versions have fixed it and broken
C-code. Too bad for the users, but it improved the compiler's C-compliance.
Something might work, but that doesn'
Perfect :)
I've been doing it wrong all the time, thinking I was improving performance.
It's good to know how things really work under the hood.
Thanks,
Ron
"Zeev Suraski" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> At 13:35 15/09/2005, Ron Kor
Yeah, it's awesome. I heard there's even a number of kids in Finland who can
speak, read and write Finnish. Awesome! ;)
Ron
"Oliver Grätz" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Jani Taskinen schrieb:
> > 10 seconds? Sheesh. If english was my native language, maybe
"Mike Bretz" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Also an useful feature would be "const" on function parameters.
Hmm, I like that ;) That may even provide a performance increasing
opportunity...
I have another idea I came up with today: regular expression switches, but
i
ot;regcase" either and it's quite a diversion from
the known syntax.
Ron
"Hartmut Holzgraefe" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Ron Korving wrote:
> > I have another idea I came up with today: regular expression switches,
but
> > it
case (preg_match('/^[0-9]+$/i', $str)):
> echo "it was a number!\n";
> break;
> default:
> echo "it was no number :-(\n";
> break;
> }
>
> *shrug*
>
> -james
&g
;foo bar');
echo "'".$doc->getElementsByTagName('body')->item(0)->textContent."'\n";
?>
Output:
'Â '
'foo bar'
Where the heck do these 'Â's come from when it parses an ? I hope
anyone can shed some light on the next step to be taken in order to fix
this.
Thanks,
Ron Korving
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
problem, but they output other bad characters.
I've tried playing with a in the HTML-data while changing
the characterset, but nothing changed.
Ron
""Ron Korving"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Hi,
>
> I found a bug in DOM. I
Damn.. I feel stupid now... Sorry guys.
Is it normal for DOM to output everything in UTF8 without an ability to
influence this? I figured that it wouldn't be a UTF8 problem because it
outputs 2 bytes, and I thought UTF8 was just 1 byte (hence the name UTF8).
Guess I was wrong.
Sorry again, I reall
""messju mohr"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
A thank you to you as well.
In general:
By the way, wouldn't it be time for trim() to start trimming off ascii
characters 160 too since that's what represents? It's no biggy, but
maybe something to consider.
Ron
--
foreach() is obviously buggy.
With this foreach it works just fine:
foreach ($array as $i => $item)
$array[$i]["bar"] = $item["foo"] * 2;
I fear this bug is not just present in PHP 5.0.5, but in older versions too.
Ron Korving
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ECTED]
> This one time, at band camp, "Ron Korving" <[EMAIL PROTECTED]> wrote:
>
> > The problem with this would be that it can't be decided on a per-case
basis,
> > but only for the whole switch, which would make the execution slower.
That's
> >
every item, because within this foreach() the
$foo's should overwrite eachother with your logic.
Ron
"Antony Dovgal" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> On 16.09.2005 16:29, Ron Korving wrote:
> > My apologies for my DOM-mistake today, but
Good point. I think it's somehow undesired behavior, but what can one do to
change this? I guess it somehow is desired behavior...
My bad I guess,
Ron
"Matthew Charles Kavanagh" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> Ron Korving wrote:
>
>
After reading the php|architect article on PDO by Ilia I have a couple of
questions:
1) Does unsetting $stmt trigger a closeCursor() as well? I assume so, but
the article doesn't mention it. It only talks about the importance of
calling that method.
2) Could it be a good idea (performance wise) an
> Ron Korving wrote:
>
> > 1) Does unsetting $stmt trigger a closeCursor() as well? I assume so,
but
> > the article doesn't mention it. It only talks about the importance of
> > calling that method.
>
> yes this is done automatically ..
Great :)
> > 2)
Marcus, you are my hero :)
Will it end up in 5.1?
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello internals,
>
> the patch implements __toString to have obejcts be automatically
converted
> to strings anywhere a string is requested. We have talked a lot
I knew I had forgotten something ;)
Ron
"Marcus Boerger" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Hello Ron,
>
> no, we declined it for 5.1 becasue it was to late in release process
> when we (i) rememebred itso blame me for not having it in 5.1, or
blame
> yourself for
> Again and for the record in this thread, I told you and here many
> times, the only safe way is to develop the new features in a separate
> code base (ext/date was planned to be used for this exact purpose
> before you decided to move your code there). A separate code base is
> the only way to ke
Well, if PHP integers are turned into int64 datatypes, there'd be more room
to operate for dates (I read in Derick's PDF that 2^31 presents problems,
and therefor abstraction by an object class helps out). Then an OO datatype
for dates wouldn't be needed.
But on the other hand, I can't say I'd min
Stanislav,
You are absolutely right. date() has always worked just fine and 100%
reliable. Maybe it wasn't suitable for certain applications, but for others
it has been very suitable. If it is decided that the date extension will be
replaced by new behavior and will break older applications, I thi
Tim,
I'm no core PHP developer (just a user) but I'm pretty convinced that
there's nothing that can be done to solve this from PHP. PHP just passes
bytes to the zlib functions (which are implemented by the zlib guys). If one
of these functions causes a segfault, there's really nothing you can do.
> handle the error. While I have not dug into the PHP code, I don't
> understand why the technique used to cap memory usage at the script
> level can't be used to detect a problem in zlib Perhaps passing a
> max memory usage parameter to gzinflate that is lower that the script
nstability (for lack of a
better word) comes from, but could it be possible for this to be resolved
for PHP6 so that PHP becomes an extremely viable solution for CLI daemon
scripts?
Thanks,
Ron Korving
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I've had PHP scripts die after weeks or months on Linux without an obvious
reason, and honestly I'm a little bit puzzled on how to debug the situation.
Any suggestions?
Ron
"James Aylett" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> On Thu, Oct 06, 2005 at 12:33:16PM +0200, Pe
ons a day with our PHP-based
daemons. We chose to try using PHP to share business logic and it paid
off.
-- Allen
-Original Message-
From: Ron Korving [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 06, 2005 2:49 AM
To: internals@lists.php.net
Subject: [PHP-DEV] CLI in PHP6
Hi,
There was o
That would be nice. If all memory, even the stuff allocated by functions, is
freed at the end of the request, I can see where the problem is. It would be
very useful if this memory really would be freed at the moment all
references to it disappear. This would be a lot better for the CLI
environment
Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing
to share with you guys...
PHP6 is a major release. BC is a priority, but as far as I'm concerned not
the top priority. I wouldn't mind a unicode-only PHP at all. Like a few
others here, I think the speed penalty won't be
I'm a big fan of coalesce($param1, $param2, ..., $paramN) (or firstset()).
The syntax allows for more than what ifsetor($var, $value) would do.
Ifsetor() could be done in userspace, but I don't see how coalesce() could,
because of the variable number of parameters.
Ron
"Sean Coates" <[EMAIL PROT
Marcus, my point was that this simple function:
function ifsetor(&$var, $value)
{
return (isset($var)) ? $var : $value;
}
can be done in userspace, and that a coalesce() like function will have the
added benefit of a variable number of parameters, which as far as I know,
cannot be done
mind this whole ifsetor() in
userspace issue, because it's not applicable anyway, but just for the
record, this function does not generate an E_NOTICE.
Ron
"Jasper Bryant-Greene" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> On Sun, 2005-10-30 at 09:52 +010
Now I'm no core developer, but I think what you fear is impossible. If I'm
not mistaken: array_merge() will write it's result to a piece of data and
when it's finished, it will make $array1 point to it, as I expect this to
work in every function that returns something.
Ron
"Ezra Nugroho" <[EM
I was wondering; we've seen quite a few PHP6 wishlists passing by here. Is
there (and if not: should there be) a centralized spot where changes and new
features are logged, perhaps with a status saying whether somebody (and who)
is working on this, or if it's still being considered, or if it has
I just read this news that an MD5 collision can now be done by anyone in 45
minutes (avg) on a P4 1.6 GHz:
http://it.slashdot.org/article.pl?sid=05/11/15/2037232&threshold=-1&tid=172&tid=93&tid=228
http://www.stachliu.com.nyud.net:8090/collisions.html
MD5 as the standard for hashing is definately
"Ilia Alshanetsky" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Ron Korving wrote:
> > I just read this news that an MD5 collision can now be done by anyone in
45
> > minutes (avg) on a P4 1.6 GHz:
> >
http://it.slashdot.org/article.pl?sid=
If anybody should know this for certain, it's core developers, hence my
question here. I'm curious if type certainty requires an extra check, or a
check less.
Which of these is faster?
if ($str === 'abc') { }
if ($str == 'abc') { }
I expect the triple '=' to be faster, but I'd like to be sure.
I hear a lot of opinions here on the curly braces issue, and while I don't
use them, they're not in the way. I'd say let's keep them in.
> > As far a code readability and obviousness goes, I doubt anybody would
> > guess their way to the $str{5} syntax. If you were new to
> > PHP and you
> > we
> On 11/25/05, Ilia Alshanetsky <[EMAIL PROTECTED]> wrote:
> > Does this include anytime a new function/class is added we need to make
> > a prominent notice about since it reserves some name space?
> Yes of course, especially if it's such an obvious name like "date".
I disagree strongly. Date is
"Rasmus Lerdorf" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Jessie Hernandez wrote:
> > Hi Marcus,
> >
> > Marcus Boerger wrote:
> >> Hello Jessie,
> >>
> >> that's only one case,go with consts. now try
> >> $x = $y ? foo:bar:baz:stupid;
> >>
> >> now what?
> >>
> >> best rega
"Jessie Hernandez" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Bob Silva wrote:
> >>$x = $y ? foo:bar:baz:stupid;
> >
> >
> > I think "stupid" is the key word here, by forcing the whitespace or (),
you
> > are making the language itself stupid by not knowing how to parse
itself.
> Speaking of this, I like Greg's suggestion about prefixing all internal
> classes with PHP_. While there are certainly classes out there that are
> prefixed with it, we could tell developers that starting with e.g. PHP 6
> the PHP_* class scope is reserved for the language core and must not be
>
wow, I like foo~>bar~>obj->method()
I love ':' best, but if that really can't be, I must say '~>' looks pretty
cool to me, cute even, like a little fishie ;)
anywaaay.. the best alternative to ':' i've seen so far, and i doubt it'll
cause problems with any existing operator.
- ron
""Ford, Mi
Well, at least now we know that 'goto' is the way to go:
http://developers.slashdot.org/developers/05/11/28/1257216.shtml?tid=156&tid=218
j/k of course :)
Ron
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 251 matches
Mail list logo
