Re: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Hi Matthias, Let alone __php__. If you just put all of your code into namespace Mylib, you're not safe because according to the name resolution rules, internal classes come after imported ones but before trying to find classes in the current namespace. I'd missed that :-( and from what I gather, there's no way to safely change it either. OK, apologies for the noise. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Matthias Pigulla wrote:
Von: Gregory Beaver [mailto:[EMAIL PROTECTED]
Exactly - which is why you should never put classes, functions or
constants in the __php__ namespace. The convention I am proposing
is to only use __php__ for code that *uses* re-usable components,
not *declares* them.
Let alone __php__. If you just put all of your code into namespace
Mylib, you're not safe because according to the name resolution
rules, internal classes come after imported ones but before trying to
find classes in the current namespace.
Right, but as long as you know this, it is not so bad for two reasons,
see below. Even if you *don't* know this, the chance of a name
collision is extremely unlikely - the most common collision will be
Exception.
1) library code is always explicitly used 2) name conflicts are
impossible
1) is the crucial one because that puts your classes ahead of the
internal ones in the resolution list. That is not only library code
you explicitly use, but also all code from your own namespace.
Having to explicitly enumerate all classes you use in your own
namespace in every file may be tedious.
So just to get that straight: Having a namespace statement and no
use (because all you use is from your library) is a discouraged
practise?
To be clear - this *only* affects users who are relying on autoload. In
other words, this code works the same way 100% of the time regardless of
load order:
file1.php:
?php
namespace foo;
class Exception {}
?
file2.php:
?php
namespace foo;
include 'file1.php';
$a = new Exception('hi');
echo get_class($a); // foo::Exception
?
So, if your code explicitly loads external files using include/require,
you need not worry about this issue.
Library authors who are in fact relying upon autoload do need to
explicitly use the classes they import as unqualified names, but this is
far less onerous than it seems on initial thought.
Let's say you're using 10 classes from your own project. The first
instinct is that you then have to have 10 use lines - what a pain!
However, this is not necessary. Here's a realistic sample from
PEAR2_Pyrus's package.xml validator class,
PEAR2::Pyrus::PackageFile::v2::Validator.
?php
namespace PEAR2::Pyrus::PackageFile::v2;
use PEAR2::Pyrus::PackageFile as pf;
use PEAR2::Pyrus::PackageFile::Exception as _ex
use PEAR2::Pyrus as me;
class Validator {...} // details removed for brevity :)
?
With the above use statements, I can access these classes:
PEAR2::Pyrus::PackageFile::v2
PEAR2::Pyrus::Validate
PEAR2::Pyrus::PackageFile::Exception
PEAR2::Pyrus::ChannelRegistry
PEAR2::Pyrus::Installer::Role
PEAR2::Pyrus::Config
PEAR2::Pyrus::Config::Exception
PEAR2::Pyrus::Task
PEAR2::Pyrus::Log
PEAR2::Pyrus::Package::Tar
with these shortcuts:
pf::v2
me::Validate
_ex
me::ChannelRegistry
me::Installer::Role
me::Config
me::Config::Exception
me::Task
me::Log
me::Package::Tar
Note that it would be possible to shorten the longer names like
me::Config::Exception, but these classnames are only used once in the
file. The most commonly used classname is
PEAR2::Pyrus::PackageFile::Exception, and so I would choose that as the
shortest name. When one examines these things from a practical
standpoint, having the 4 extra characters me:: definitely increases
maintainability, as it makes it obvious that this class is from our
library, and not an internal class.
I do think it would be worth putting future internal classes into the
PHP namespace, and it would be a good idea to reserve that namespace
now. The reservation can always be dropped later if necessary.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Garbage collector patch
Hi Ilia, I suggest more people test the performance difference because as you can see for us it was negligible. From my experience you see bigger deviations just by moving kernels, compilers, and even small patches which affect where in memory the code segments sit, etc... Maybe some people here who have performance harnesses (I'm sure Yahoo! has one) could test it too. Andi -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Saturday, December 08, 2007 9:35 AM To: [EMAIL PROTECTED] Cc: Rasmus Lerdorf; Stas Malyshev; [EMAIL PROTECTED]; 'Antony Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Richard, zval is such a common PHP structure that in a scope of a single script (even a trivial one) you'd have thousands of them. Therefor even an extra 4 bytes matter, and for people with large application it would matter even more. I wish the patch was such that it had no impact on the people who don't need it, but the reality is that for anyone who does not need gc cycles, it'll be a performance (speed memory) penalty. This is why I had intimately suggested making it a compile time, configuration option. On 7-Dec-07, at 9:25 PM, Richard Lynch wrote: On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: 1. Always compile it in but leave undocumented #ifdefs in place for performance freaks. Those same performance freaks aren't going to care about the binary compatibility issue since they are the same people who build all their own stuff. Note that breaking BC is not only about performance - one your build is not the same as mainstream PHP, you can't use any binary extension which would do anything non-performance-related - like interfacing some external system/library, debugging, profiling, testing, security and so on. Any commercial module won't be available for the user of this switch, and all open-source modules one'd have to build by oneself, which may be serious maintenance issue. I know there are a bunch of companies that compile PHP with their own options but still use commercial modules, including both performance and non-performance ones. They couldn't use this compile switch. Yes, I know what binary compatibility means. Call me crazy, but... Would it be possible to hard-code the bit that adds the 4 bytes to the zval, but make the execution bit a flag so that binary compatibility is always there, but the executable code that does the GC can come or go as needed?... Or am I just talking nonsense due to ignorance? -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Test case for bug #43495
Heya, I wondered why bug #43495 [1] (array_merge_recursive crash with recursive arrays) was fixed without committing a test case -- the bug reporter even supplied a very simple reproduce code. As such, I'm submitting a small test case [2] (more or less the reproduce code from the bug report) in the hope that someone will commit it. It should go to ext/standard/tests/array/, I suppose. [1] http://bugs.php.net/bug.php?id=43495 [2] http://rafb.net/p/xv0htM54.html -- Thanks in advance, Christian Hoffmann -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
On 07/12/2007, Lokrain [EMAIL PROTECTED] wrote: Hello all, I just wanted to drop an opp. Just to see the logic, when we have programming structure class, interface, function, if statement, switch statement etc, we have bracers encapsulation. This is the logic that most programming language give to show a programmer that something is inside something. We here have namespace with the same idea, and no bracers. Conclusion: namespaces are not logical = no thanks PS. By the way, I do not think that any workarounds on that logic will not be nice. I'm trying to understand the argument against using braces. And that has led me to the following question. Assuming no braces, how would I put code OUTSIDE of the namespace in a single file. ?php namespace XYZ; xyz related code goes here non xyz related code goes here but how do I let PHP know it isn't part of xyz? Do I have to change namespace by using a dummy namespace? Same issue how do I refer to the global namespace. Richard. -- - Richard Quadling Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731 Standing on the shoulders of some very clever giants! -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.3 bug or changed feature??
Hi Frank,
please open a bugreport about this issue. This would start the internal
process of verifying this.
-- Marco
On Dec 7, 2007 11:09 PM, Frank M. Kromann [EMAIL PROTECTED] wrote:
Hello Everyon,
Casting a SimpleXML object to an array gives different results in PHP
5.2.5 and PHP 5.3-dev.
Source:
$xml = simplexml_load_file(sample.xml);
foreach($xml-column as $column) {
var_dump($column);
var_dump((array)$column);
}
sample.xml
?xml version=1.0?
cpdata
column name=ENTERTAINMENT
modulecv/module
moduleentsimp/module
/column
column name=SEAT CONTROL
modulepp/module
modulesc/module
/column
/cpdata
PHP 5.2 output:
object(SimpleXMLElement)#4 (2) {
[@attributes]=
array(1) {
[name]=
string(13) ENTERTAINMENT
}
[module]=
array(2) {
[0]=
string(2) cv
[1]=
string(7) entsimp
}
}
array(2) {
[@attributes]=
array(1) {
[name]=
string(13) ENTERTAINMENT
}
[module]=
array(2) {
[0]=
string(2) cv
[1]=
string(7) entsimp
}
}
object(SimpleXMLElement)#5 (2) {
[@attributes]=
array(1) {
[name]=
string(12) SEAT CONTROL
}
[module]=
array(2) {
[0]=
string(2) pp
[1]=
string(2) sc
}
}
array(2) {
[@attributes]=
array(1) {
[name]=
string(12) SEAT CONTROL
}
[module]=
array(2) {
[0]=
string(2) pp
[1]=
string(2) sc
}
}
PHP 5.3 output:
object(SimpleXMLElement)#4 (2) {
[@attributes]=
array(1) {
[name]=
string(13) ENTERTAINMENT
}
[module]=
array(2) {
[0]=
string(2) cv
[1]=
string(7) entsimp
}
}
array(1) {
[module]=
array(2) {
[0]=
string(2) cv
[1]=
string(7) entsimp
}
}
object(SimpleXMLElement)#5 (2) {
[@attributes]=
array(1) {
[name]=
string(12) SEAT CONTROL
}
[module]=
array(2) {
[0]=
string(2) pp
[1]=
string(2) sc
}
}
array(1) {
[module]=
array(2) {
[0]=
string(2) pp
[1]=
string(2) sc
}
}
Not that the attributes are gone when SimpleXML objects are converted in
PHP 5.3. Is this a bug or a feature change?
- Frank
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
Marco Kaiser
Re: [PHP-DEV] Test case for bug #43495
On 08.12.2007 23:12, Christian Hoffmann wrote: Heya, I wondered why bug #43495 [1] (array_merge_recursive crash with recursive arrays) was fixed without committing a test case http://cvs.php.net/viewvc.cgi/php-src/ext/standard/tests/array/bug43495.phpt ?? -- the bug reporter even supplied a very simple reproduce code. As such, I'm submitting a small test case [2] (more or less the reproduce code from the bug report) in the hope that someone will commit it. It should go to ext/standard/tests/array/, I suppose. [1] http://bugs.php.net/bug.php?id=43495 [2] http://rafb.net/p/xv0htM54.html -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Test case for bug #43495
On 12/08/2007 09:18 PM, Antony Dovgal wrote: On 08.12.2007 23:12, Christian Hoffmann wrote: Heya, I wondered why bug #43495 [1] (array_merge_recursive crash with recursive arrays) was fixed without committing a test case http://cvs.php.net/viewvc.cgi/php-src/ext/standard/tests/array/bug43495.phpt ?? D'oh... I'm very sorry. No clue why I missed that in the commit notification mail. :( Again, sorry for the noise. -- Christian Hoffmann -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Garbage collector patch
Sorry to intrude on this one! It seems that some real hard work has gone into this, and a big thanks from the community for all your hard work. Can the gc patch feasibly be improved any more? If so surely the time scales involved with improving further would mean it'd miss the boat for a 5.3.x release..? Real-life use of PHP has to be the foremost concideration; in the production environment, especially on server farms and shared hosts, how many of them are going to be upgraded to 5.3 anyways, and when so, not for a long time (sadly)! 4 bytes vs the earlier 12 bytes is a significant improvement, and much as this may seem a terrible thing to say.. Roll it out in 5.3, turned on by default (with option to disable at compile time) - that's your test right there, if there are problems then have it disabled by default in the subsequent minor release. My only (and major) concern as an end developer is the 5% slowdown and 3% memory overhead, exactly what benefit am I as an end developer going recieve for this? Andi started this series with : On one hand I think now the effort has been made it's a good thing to offer it as part of PHP; and I for one agree, with the emphasis on *offer*. Many Regards Apologies for the intrusion. Nathan Andi Gutmans wrote: Hi Ilia, I suggest more people test the performance difference because as you can see for us it was negligible. From my experience you see bigger deviations just by moving kernels, compilers, and even small patches which affect where in memory the code segments sit, etc... Maybe some people here who have performance harnesses (I'm sure Yahoo! has one) could test it too. Andi -Original Message- From: Ilia Alshanetsky [mailto:[EMAIL PROTECTED] Sent: Saturday, December 08, 2007 9:35 AM To: [EMAIL PROTECTED] Cc: Rasmus Lerdorf; Stas Malyshev; [EMAIL PROTECTED]; 'Antony Dovgal'; Andi Gutmans; 'Cristian Rodriguez'; internals@lists.php.net Subject: Re: [PHP-DEV] Garbage collector patch Richard, zval is such a common PHP structure that in a scope of a single script (even a trivial one) you'd have thousands of them. Therefor even an extra 4 bytes matter, and for people with large application it would matter even more. I wish the patch was such that it had no impact on the people who don't need it, but the reality is that for anyone who does not need gc cycles, it'll be a performance (speed memory) penalty. This is why I had intimately suggested making it a compile time, configuration option. On 7-Dec-07, at 9:25 PM, Richard Lynch wrote: On Tue, December 4, 2007 2:18 pm, Rasmus Lerdorf wrote: Stanislav Malyshev wrote: 1. Always compile it in but leave undocumented #ifdefs in place for performance freaks. Those same performance freaks aren't going to care about the binary compatibility issue since they are the same people who build all their own stuff. Note that breaking BC is not only about performance - one your build is not the same as mainstream PHP, you can't use any binary extension which would do anything non-performance-related - like interfacing some external system/library, debugging, profiling, testing, security and so on. Any commercial module won't be available for the user of this switch, and all open-source modules one'd have to build by oneself, which may be serious maintenance issue. I know there are a bunch of companies that compile PHP with their own options but still use commercial modules, including both performance and non-performance ones. They couldn't use this compile switch. Yes, I know what binary compatibility means. Call me crazy, but... Would it be possible to hard-code the bit that adds the 4 bytes to the zval, but make the execution bit a flag so that binary compatibility is always there, but the executable code that does the GC can come or go as needed?... Or am I just talking nonsense due to ignorance? -- Some people have a gift link here. Know what I want? I want you to buy a CD from some indie artist. http://cdbaby.com/from/lynch Yeah, I get a buck. So? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ilia Alshanetsky -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace
Once you say namespace xyz ; everything in the file is now relative to
namespace xyz. To refer to the global namespace, you use the following
?php
namespace xyz ;
function substr() {
return true ;
}
substr(); // calls substr in current namespace
::substr(); // calls substr in global namespace
?
On Sat, 2007-12-08 at 20:12 +, Richard Quadling wrote:
On 07/12/2007, Lokrain [EMAIL PROTECTED] wrote:
Hello all,
I just wanted to drop an opp. Just to see the logic, when we have
programming structure class, interface, function, if statement, switch
statement etc, we have bracers encapsulation. This is the logic that most
programming language give to show a programmer that something is inside
something. We here have namespace with the same idea, and no bracers.
Conclusion: namespaces are not logical = no thanks
PS. By the way, I do not think that any workarounds on that logic will not
be nice.
I'm trying to understand the argument against using braces.
And that has led me to the following question.
Assuming no braces, how would I put code OUTSIDE of the namespace in a
single file.
?php
namespace XYZ;
xyz related code goes here
non xyz related code goes here but how do I let PHP know it isn't part of xyz?
Do I have to change namespace by using a dummy namespace? Same issue
how do I refer to the global namespace.
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Type hinting
A few weeks ago I wrote a message on this list about my patch for scalar
type hinting. I've been using it for about a month now in a large scale
application im developing with no problems. It allows type hinting for
the following types: int, float, string, bool (boolean), num (int or
float), scalar (int, float, string, or bool), object, and resource.
All of these types have been very useful. Num has been useful for any
mathematical functions, scalar has been the most useful, mostly for
echoing values and interacting with the database (as a database cant
store arrays or objects).
The type hinting is all 100% optional and has caused no problems for me
at all, I use it in most function but some functions I'll use it for one
parameter and not the other, or none at all with no problems.
What is the general opinion on this? Examples below:
?php
function multiply(num $a, num b) {
return $a * $b ;
}
multiply(5, 1) ; // works
multiply(3.7, 8.2) // works
multiply(foo, 5) ; // Catchable fatal error: Argument 1 passed to
multiply() must be a number, string given
function displayStuff(scalar $stuff) {
echo $stuff ;
}
displayStuff('Hello!') ; // works
displayStuff(123) ; // works
displayStuff(array('a' = 'b')) ; // Catchable fatal error: Argument 1
passed to displayStuff() must be a scalar, array given
?
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] Namespace
Quick question... If I wanted to override or extend php's functions... Could
this work?
Say I want to change the implementation of var_dump() to make it more html
friendly...
function var_dump($mixedVariable)
{
echo('pre');
::var_dump($mixedVariable);
echo('/pre');
}
SCOTT MCNAUGHT
Software Developer
Synergy 8 / +617 3397 5212
[EMAIL PROTECTED]
-Original Message-
From: Sam Barrow [mailto:[EMAIL PROTECTED]
Sent: Sunday, 9 December 2007 7:23 AM
To: [EMAIL PROTECTED]
Cc: Lokrain; internals@lists.php.net
Subject: Re: [PHP-DEV] Namespace
Once you say namespace xyz ; everything in the file is now relative to
namespace xyz. To refer to the global namespace, you use the following
?php
namespace xyz ;
function substr() {
return true ;
}
substr(); // calls substr in current namespace
::substr(); // calls substr in global namespace
?
On Sat, 2007-12-08 at 20:12 +, Richard Quadling wrote:
On 07/12/2007, Lokrain [EMAIL PROTECTED] wrote:
Hello all,
I just wanted to drop an opp. Just to see the logic, when we have
programming structure class, interface, function, if statement, switch
statement etc, we have bracers encapsulation. This is the logic that
most
programming language give to show a programmer that something is inside
something. We here have namespace with the same idea, and no bracers.
Conclusion: namespaces are not logical = no thanks
PS. By the way, I do not think that any workarounds on that logic will
not
be nice.
I'm trying to understand the argument against using braces.
And that has led me to the following question.
Assuming no braces, how would I put code OUTSIDE of the namespace in a
single file.
?php
namespace XYZ;
xyz related code goes here
non xyz related code goes here but how do I let PHP know it isn't part of
xyz?
Do I have to change namespace by using a dummy namespace? Same issue
how do I refer to the global namespace.
Richard.
--
-
Richard Quadling
Zend Certified Engineer : http://zend.com/zce.php?c=ZEND002498r=213474731
Standing on the shoulders of some very clever giants!
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Thoughts on Feature Request - Arithmetic
The solution is already in pear : http://pear.php.net/package/Math_RPN
[PHP-DEV] faster public domain MD5 implementation
Hi,
Attached is a quick patch for PHP 5.2.5 that replaces RSA's copyrighted
implementation of MD5 with my public domain one:
http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/md5/
This also results in faster and slightly smaller code (both source and
binary). On a Pentium 3 that I've tested this on, the speedup is 12%
for the portable hashes as implemented in phpass:
http://www.openwall.com/phpass/
Given that most CPU time is spent on various overhead of the PHP
interpreter rather than on MD5 hashing itself (and gprof confirms this),
the 12% speedup seen on the PHP script as a whole means that the speedup
for the MD5 implementation alone is much higher than that. The speedup
should be similar on other little-endian CPUs (other x86 CPUs, x86-64,
Alpha), but smaller on big-endian.
The code can be made cleaner by taking my md5.[ch] files as they are and
introducing two files more for PHP's added functions. I did not do it
for this patch in order for my changes to be less invasive.
I also did not similarly replace the MD5 implementation in hash_md.c,
which obviously will need to be done (once again, I'd prefer that
separate md5.[ch] files are used - and perhaps only one instance of them
included in the PHP distribution).
I also wrote a similar public domain implementation of MD4, which I can
provide for inclusion in hash_md.c if there's any interest.
Finally, it'd be nice if PHP could optionally link against OpenSSL
libcrypto to take advantage of the architecture-specific implementations
of these hashes. My implementations of MD5 and MD4 are function
prototype compatible with OpenSSL's.
I'd appreciate being CC'ed on any follow-ups as I am not on the list.
Thanks,
--
Alexander Peslyak solar at openwall.com
GPG key ID: 5B341F15 fp: B3FB 63F4 D7A3 BCCC 6F6E FC55 A2FC 027C 5B34 1F15
http://www.openwall.com - bringing security into open computing environments
--- php-5.2.5/ext/standard/md5.h.orig 2007-05-20 00:30:35 +0400
+++ php-5.2.5/ext/standard/md5.h2007-12-09 03:25:05 +0300
@@ -20,45 +20,26 @@
#ifndef MD5_H
#define MD5_H
-/* MD5.H - header file for MD5C.C
- */
-
-/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
- rights reserved.
-
- License to copy and use this software is granted provided that it
- is identified as the RSA Data Security, Inc. MD5 Message-Digest
- Algorithm in all material mentioning or referencing this software
- or this function.
-
- License is also granted to make and use derivative works provided
- that such works are identified as derived from the RSA Data
- Security, Inc. MD5 Message-Digest Algorithm in all material
- mentioning or referencing the derived work.
-
- RSA Data Security, Inc. makes no representations concerning either
- the merchantability of this software or the suitability of this
- software for any particular purpose. It is provided as is
- without express or implied warranty of any kind.
-
- These notices must be retained in any copies of any part of this
- documentation and/or software.
- */
#include ext/standard/basic_functions.h
+/* Any 32-bit or wider unsigned integer data type will do */
+typedef unsigned int MD5_u32plus;
+
/* MD5 context. */
typedef struct {
- php_uint32 state[4];/* state (ABCD) */
- php_uint32 count[2];/* number of bits,
modulo 2^64 (lsb first) */
- unsigned char buffer[64]; /* input buffer */
+ MD5_u32plus lo, hi;
+ MD5_u32plus a, b, c, d;
+ unsigned char buffer[64];
+ MD5_u32plus block[16];
} PHP_MD5_CTX;
+PHPAPI void PHP_MD5Init(PHP_MD5_CTX *ctx);
+PHPAPI void PHP_MD5Update(PHP_MD5_CTX *ctx, void *data, unsigned long size);
+PHPAPI void PHP_MD5Final(unsigned char *result, PHP_MD5_CTX *ctx);
+
PHPAPI void make_digest(char *md5str, unsigned char *digest);
PHPAPI void make_digest_ex(char *md5str, unsigned char *digest, int len);
-PHPAPI void PHP_MD5Init(PHP_MD5_CTX *);
-PHPAPI void PHP_MD5Update(PHP_MD5_CTX *, const unsigned char *, unsigned int);
-PHPAPI void PHP_MD5Final(unsigned char[16], PHP_MD5_CTX *);
PHP_NAMED_FUNCTION(php_if_md5);
PHP_NAMED_FUNCTION(php_if_md5_file);
--- php-5.2.5/ext/standard/md5.c.orig 2007-05-27 19:29:38 +0400
+++ php-5.2.5/ext/standard/md5.c2007-12-09 03:25:15 +0300
@@ -119,316 +119,260 @@ PHP_NAMED_FUNCTION(php_if_md5_file)
/* }}} */
/*
- * The remaining code is the reference MD5 code (md5c.c) from rfc1321
+ * The remaining code is Solar Designer's public domain implementation of MD5,
+ * with only some identifiers renamed to match the rest of PHP code.
*/
-/* MD5C.C - RSA Data Security, Inc., MD5 message-digest algorithm
- */
-
-/* Copyright (C) 1991-2, RSA Data Security, Inc. Created 1991. All
- rights reserved.
-
- License to copy and use this software is granted provided that it
- is identified as the RSA Data Security, Inc. MD5 Message-Digest
- Algorithm
Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Hi Greg, How about this: any non-namespaced file that uses use statements is implicitly put into the __php__ namespace (or whatever other name is chosen, or having the namespace name be the path of the file)? With this, use will never import any symbols into the global namespace. Regards, Jessie Ford, Mike wrote: On 07 December 2007 17:36, Gregory Beaver wrote: The suggestion to make namespace __php__; implicit is very interesting, but would defeat its purpose, which is to separate declarations from use. Oh, I missed that little wrinkle -- I did say I was only skimming! I guess it could still be done, but at somewhat greater cost in the engine than I was imagining, which probably isn't worthwhile. Cheers! Mike - Mike Ford, Electronic Information Services Adviser, JG125, The Headingley Library, James Graham Building, Leeds Metropolitan University, Headingley Campus, LEEDS, LS6 3QS, United Kingdom Email: [EMAIL PROTECTED] Tel: +44 113 812 4730 Fax: +44 113 812 3211 To view the terms under which this email is distributed, please go to http://disclaimer.leedsmet.ac.uk/email.htm -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: AW: [PHP-DEV] A rebuttal to Re: RFC: Dropping Namespace
Jessie Hernandez wrote:
Hi Greg,
How about this: any non-namespaced file that uses use statements is
implicitly put into the __php__ namespace (or whatever other name is
chosen, or having the namespace name be the path of the file)? With
this, use will never import any symbols into the global namespace.
Hi Jessie,
Imagine how that would affect this code:
file1.php:
?php
function doSomething() {}
?
PEAR2/DB.php: hypothetical
?php
namespace PEAR2;
class DB {}
?
file2.php:
?php
include 'file1.php';
include 'PEAR2/DB.php';
use PEAR2::DB;
$a = new DB;
$b = doSomething();
?
In file2.php, because there is a use statement, the rest of the file
is assumed to be in the __php__ namespace. As such, the file can be
expanded into this code:
new_file2.php:
?php
namespace __php__;
include 'file1.php';
include 'file2.php';
$a = new PEAR2::DB;
$b = doSomething();
?
On the last line, when PHP calls doSomething(), it first checks to see
if the function doSomething is available as an internal function.
Then, it tries __php__::doSomething() and fails on a fatal error because
the function does not exist. The only way that your idea would work is
if the check for doSomething consisted of checking for any
non-namespaced function (not just internal functions), but the sole
purpose of the fall-through is to allow users to call internal
functions/classes without explicitly specifying ::strlen or ::count and
so on. Allowing fall-through to any global class/function would serve
to dilute the namespacing effect, but perhaps this is a good thing? I
have not thought about this long enough to have a definitive opinion yet.
I think one safe way to handle this might be to have an E_STRICT if
class/function/const is declared in the __php__ namespace, so that PHP
provides a clear mechanism for enforcing the convention. Users wishing
to avoid this E_STRICT need only use another namespace name or adhere to
the coding convention of only putting stuff that uses code into the
__php__ namespace.
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
