Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Fri, 21 Dec 2007 23:14:02 +0100, Pierre <[EMAIL PROTECTED]> wrote: > On Dec 21, 2007 9:55 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: >> >> Only thing needed for this is willingness to actually listen. >> > >> > Listen the masses: NO, we don't want CLAs in php.net, period. >> >> I like when people call themselves "masses", it is amusing. > > I don't know how much answers you need to finally accept a fact... > Don't be blind, you perfectly see all other opinions from other > developers. Would a poll, or a vote on the un/acceptance make any sense? --Chris > > -- > Pierre > http://blog.thepimp.net | http://www.libgd.org > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php / Service provided by hitOmeter.NET internet messaging! . -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Refactoring code for namespaces appliance
2007/12/21, Paul Biggar <[EMAIL PROTECTED]>:
>
> Hi Martin,
>
> On Dec 21, 2007 8:30 PM, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> > I've been pondering about how to algorithmically/mechanically prepare a
> non
> > namespaced code for namespaces appliance. This would be a first step
> which
> > will just prepare the code for namespaces in a safe way, but not to
> profit
> > from aliases created by use. The latest will have to be implemented
> manually
> > (IMHO).
>
> phc (www.phpcompiler.org) would be suitable for this purpose. It has
> good support for nearly all of the features you need.
Thank you, that looks like it's the tool for the job.
> 4) find all function calls (not method calls) which are not keywords
> (array,
> > isset, unset, list, etc) and prefix them with ::
>
> list, array etc wouldnt be confused with functions. Functions are just
> methods without target. You'd need a short list of functions such as
> empty, unset etc to avoid.
I didn't quite understand your point here. If you can elaborate a little
more.
Take into consideration that the reason here for the distinction between
function calls which are actually keywords are due to the fact that the
following wouldn't be valid:
if (::isset($var)) {
Because isset is actually a keyword.
And to ensure that the code is ported safely to code which uses namespaces,
the function calls which point to globals or internal functions, should be
prefixed with ::
> 6) find static method calls with variables used as class name, and mark
> them
> > for user handled refactoring
>
> I'm not sure why this couldnt be done automatically, but finding
> static method calls is also easy. You could add comments to mark these
> fairly easily.
Maybe some workaround can be found to str_replace the namespace separator,
but I think this wouldn't be optimal and possibly harm code readability and
maintainability. Consider a factory method:
An automated refactoring would be tempted to do:
Which I think is not the proper way to refactorize this code.
This would be, IMHO, the right way to refactorize this code:
Considering the variants and possible uses of this syntax, I'll say it's
better to leave this job to the coder rather than to an automated job.
Thank you for your response.
Best Regards,
Martin Alterisio
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Dec 21, 2007 9:55 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > >> Only thing needed for this is willingness to actually listen. > > > > Listen the masses: NO, we don't want CLAs in php.net, period. > > I like when people call themselves "masses", it is amusing. I don't know how much answers you need to finally accept a fact... Don't be blind, you perfectly see all other opinions from other developers. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Refactoring code for namespaces appliance
Hi Martin, On Dec 21, 2007 8:30 PM, Martin Alterisio <[EMAIL PROTECTED]> wrote: > I've been pondering about how to algorithmically/mechanically prepare a non > namespaced code for namespaces appliance. This would be a first step which > will just prepare the code for namespaces in a safe way, but not to profit > from aliases created by use. The latest will have to be implemented manually > (IMHO). phc (www.phpcompiler.org) would be suitable for this purpose. It has good support for nearly all of the features you need. > I've come up with the following, for an organization model of a class per > file. > Please review. > > 1) find the class definition and reduce the class name to namespace/class > 2) add namespace declaration on top of file > 3) replace class name in definition with short name So far this would be trivial. > 4) find all function calls (not method calls) which are not keywords (array, > isset, unset, list, etc) and prefix them with :: list, array etc wouldnt be confused with functions. Functions are just methods without target. You'd need a short list of functions such as empty, unset etc to avoid. > 5) find all class names (static method calls (no self:: nor parent::), new, > catch, type hints, instanceof, extends, implements) and: All of these are trivial. > 5a) replace separator used (possibly: _) with namespace separator (::) > 5b) IF the class has no namespace (ie global namespace) prefix the class > name with :: > 5c) IF the namespace of the class starts with the same namespace found in > (1), remove it or prefix it with namespace:: > (although this is not necessary) This would be easy too. > 6) find static method calls with variables used as class name, and mark them > for user handled refactoring I'm not sure why this couldnt be done automatically, but finding static method calls is also easy. You could add comments to mark these fairly easily. > 7) find internal functions that use callables (call_user_func, array_map, > array_filter, etc) and mark them for user handled refactoring A lot of this could be automated, but there would of course be some which would require marking. > Later on, a methodical way of adding use statements for reducing the class > names used, can be implemented. Although this might be more complicate than > it seems if the method has to be careful to avoid creating possible name > clashes. > > If anyone has a comment on this, I'll be more than grateful if you share. If you need any advice, on this, please let me know. Paul -- Paul Biggar [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Refactoring code for namespaces appliance
Has anyone tried refactoring a "real world" application/library to use namespaces? I've been pondering about how to algorithmically/mechanically prepare a non namespaced code for namespaces appliance. This would be a first step which will just prepare the code for namespaces in a safe way, but not to profit from aliases created by use. The latest will have to be implemented manually (IMHO). I've come up with the following, for an organization model of a class per file. Please review. 1) find the class definition and reduce the class name to namespace/class 2) add namespace declaration on top of file 3) replace class name in definition with short name 4) find all function calls (not method calls) which are not keywords (array, isset, unset, list, etc) and prefix them with :: 5) find all class names (static method calls (no self:: nor parent::), new, catch, type hints, instanceof, extends, implements) and: 5a) replace separator used (possibly: _) with namespace separator (::) 5b) IF the class has no namespace (ie global namespace) prefix the class name with :: 5c) IF the namespace of the class starts with the same namespace found in (1), remove it or prefix it with namespace:: (although this is not necessary) 6) find static method calls with variables used as class name, and mark them for user handled refactoring 7) find internal functions that use callables (call_user_func, array_map, array_filter, etc) and mark them for user handled refactoring Later on, a methodical way of adding use statements for reducing the class names used, can be implemented. Although this might be more complicate than it seems if the method has to be careful to avoid creating possible name clashes. If anyone has a comment on this, I'll be more than grateful if you share. Best Regards, Martin Alterisio
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On Dec 21, 2007 7:38 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > Only thing needed for this is willingness to actually listen. Listen the masses: NO, we don't want CLAs in php.net, period. -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Sounds to me like we should stop accepting this legal BS. Then they will only be able to pay for a nice little house if they write understandable stuff or nothing is they are unwilling to adapt to the demands of their customers. It is quite impossible to write anything understandable for the person that refuses to understand. Yes, legal stuff can be complicated for the outsider - as programming stuff can be complicated for the outsider. But as program design can be explained in relatively simple terms, so in many cases can the legal stuff - of course, in both cases some tiny details might get omitted, but you'd get the general picture. Only thing needed for this is willingness to actually listen. I understand that some here are so averted by the idea of the CLA itself that they are not willing even to listen what that dreaded CLA is. I get this, but it would be a hypocrisy to blame it on "not understandable stuff" if one has no intention to understand anything at the first place, only to refuse it. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
Thanks! I didn't know about that. 2007/12/21, David Zülke <[EMAIL PROTECTED]>: > > Not entirely correct. As I pointed out in the other thread, not all > countries have the concept of transferrable copyright. Therefor, a > note should be added that explicitly states that everyone is free to > use it without permission, fees etc. Much like a BSD or MIT license, > but without the additional conditions of preserving copyright notices. > > > > David > > > > Am 21.12.2007 um 14:29 schrieb Martin Alterisio: > > > No, public domain isn't recognized by copyright law as a copyright > > notice. > > An extra line should be added that says something like "no copyright > > is > > claimed", and attach a year range where the copyright is in effect > > (since > > copyright expires, if I remember correctly). Anyway, the keyword > > here is > > "copyright", which is recognized internationally (which means you > > should use > > this word even if writing the copyright notice in another language). > > > > Without a copyright notice, the code isn't apt for distribution. The > > author > > could claim that he did not give his consent for public distribution > > and > > that the code was an in-house development. Anyway, it's too > > complicate and I > > understand very little. To get the real facts here, you should talk > > to your > > lawyer. > > > > 2007/12/21, Alexey Zakhlestin <[EMAIL PROTECTED]>: > >> > >> isn't "public domain" specific enough? > >> > >> On 12/21/07, Martin Alterisio <[EMAIL PROTECTED]> wrote: > >>> 2007/12/20, Stanislav Malyshev <[EMAIL PROTECTED]>: > > > 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/ > > Tried that one and it is about 30% faster indeed (on md5-only > >> benchmark, > 32-bit Linux on AMD Opteron. Anybody objects to accepting this? > > > >>> Just one, but is a mere formality. I didn't see any copyright > >>> notice on > >> the > >>> code nor a licensing document attached. I have not much of the legal > >>> mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't > >> external > >>> code that's to be included in the php codebase meet these legal > >> formalities > >>> so it doesn't become a liability? > >>> > >>> That's all. > >>> > >>> Best Regards, > >>> > >>> Martin Alterisio > >>> > >>> PS: Does anyone knows if using a nickname for authorship is > >>> considered > >>> legally valid? I believe it might be valid, think about writers > >>> that use > >>> such pseudonyms, but I'm not sure... > >>> > >> > >> > >> -- > >> Alexey Zakhlestin > >> http://blog.milkfarmsoft.com/ > >> > >
Re: [PHP-DEV] Will pay for fixes for bugs in PDO/PDO_ODBC
Would someone be willing to apply the patch the Wez emailed in? That would at least enable me to upgrade to the latest version of php once it is in a released version. I'd still love to get a fix for bug #36561 [PDO_ODBC/MSSQL does not work with bound params in subquery], anyone interested? Name a price, hourly rate, whatever, as long as I still get to keep my firstborn... ;) --Travis On Dec 18, 2007 10:48 AM, Wez Furlong <[EMAIL PROTECTED]> wrote: > Derick, > > Your statement is not accurate: > http://cvs.php.net/viewvc.cgi/CVSROOT/avail?r1=1.1200&r2=1.1201 > > This should not be a blocker to anyone that wants to take this up. > > I've been too busy to help Travis (I'm really sorry about that > Travis), and I'm happy to share the pending fix with anyone that wants > to look at this. > > The reason that the code hasn't gone into CVS is that Travis had a > knack for picking a tree freeze for bringing up his issues, and then I > would subsequently become too busy to get the code sync'd up after the > freeze. > > Anyhow, if anyone does want to take Travis up on his offer, you'll > need the attached patch. > > > --Wez. > > PS: More on PDO soon; it has not been forgotten despite sickness, work > and so forth. > > On Dec 18, 2007, at 10:53 AM, Derick Rethans wrote: > > > On Tue, 18 Dec 2007, Travis Raybold wrote: > > > >> I've been trying to find someone who could help me with a fix for a > >> few bugs > >> in PDO_ODBC, and had no luck so far. I am more than happy to > >> compensate > >> someone for the time spent fixing these bugs. > > > > Unfortunately it is not that easy as it seems. For some reason the > > pecl/pdo_odbc and php-src/ext/pdo_odb directories are locked out for > > the "normal" PHP team and thus we can't commit to it. The comment in > > the > > rights file says: > > > > # DB2, SDO, IDS have tighter restrictions, so that IBM are not overly > > # legally encumbered. If you have contributions for these two > > extensions, > > # please contact the lead developers. This is a temporary measure > > until > > # we can put in place a more general process. > > > > It has been in this temporary situation since June 2005 :-/ > > > > regards, > > Derick > > > > -- > > Derick Rethans > > http://derickrethans.nl | http://ezcomponents.org | http://xdebug.org > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] faster & public domain MD5 implementation
Not entirely correct. As I pointed out in the other thread, not all countries have the concept of transferrable copyright. Therefor, a note should be added that explicitly states that everyone is free to use it without permission, fees etc. Much like a BSD or MIT license, but without the additional conditions of preserving copyright notices. David Am 21.12.2007 um 14:29 schrieb Martin Alterisio: No, public domain isn't recognized by copyright law as a copyright notice. An extra line should be added that says something like "no copyright is claimed", and attach a year range where the copyright is in effect (since copyright expires, if I remember correctly). Anyway, the keyword here is "copyright", which is recognized internationally (which means you should use this word even if writing the copyright notice in another language). Without a copyright notice, the code isn't apt for distribution. The author could claim that he did not give his consent for public distribution and that the code was an in-house development. Anyway, it's too complicate and I understand very little. To get the real facts here, you should talk to your lawyer. 2007/12/21, Alexey Zakhlestin <[EMAIL PROTECTED]>: isn't "public domain" specific enough? On 12/21/07, Martin Alterisio <[EMAIL PROTECTED]> wrote: 2007/12/20, Stanislav Malyshev <[EMAIL PROTECTED]>: 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/ Tried that one and it is about 30% faster indeed (on md5-only benchmark, 32-bit Linux on AMD Opteron. Anybody objects to accepting this? Just one, but is a mere formality. I didn't see any copyright notice on the code nor a licensing document attached. I have not much of the legal mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't external code that's to be included in the php codebase meet these legal formalities so it doesn't become a liability? That's all. Best Regards, Martin Alterisio PS: Does anyone knows if using a nickname for authorship is considered legally valid? I believe it might be valid, think about writers that use such pseudonyms, but I'm not sure... -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] CVS Account Request: asbjornit
Fix a few bugs, in the documentation, and in the longer run helping out with the core. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
No, public domain isn't recognized by copyright law as a copyright notice. An extra line should be added that says something like "no copyright is claimed", and attach a year range where the copyright is in effect (since copyright expires, if I remember correctly). Anyway, the keyword here is "copyright", which is recognized internationally (which means you should use this word even if writing the copyright notice in another language). Without a copyright notice, the code isn't apt for distribution. The author could claim that he did not give his consent for public distribution and that the code was an in-house development. Anyway, it's too complicate and I understand very little. To get the real facts here, you should talk to your lawyer. 2007/12/21, Alexey Zakhlestin <[EMAIL PROTECTED]>: > > isn't "public domain" specific enough? > > On 12/21/07, Martin Alterisio <[EMAIL PROTECTED]> wrote: > > 2007/12/20, Stanislav Malyshev <[EMAIL PROTECTED]>: > > > > > > > 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/ > > > > > > Tried that one and it is about 30% faster indeed (on md5-only > benchmark, > > > 32-bit Linux on AMD Opteron. Anybody objects to accepting this? > > > > > > > > Just one, but is a mere formality. I didn't see any copyright notice on > the > > code nor a licensing document attached. I have not much of the legal > > mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't > external > > code that's to be included in the php codebase meet these legal > formalities > > so it doesn't become a liability? > > > > That's all. > > > > Best Regards, > > > > Martin Alterisio > > > > PS: Does anyone knows if using a nickname for authorship is considered > > legally valid? I believe it might be valid, think about writers that use > > such pseudonyms, but I'm not sure... > > > > > -- > Alexey Zakhlestin > http://blog.milkfarmsoft.com/ >
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
On 21.12.2007, at 10:08, David Zülke wrote: I wonder why they need such elaborate bla bla to just say so trivial things. The copyright part seems irrelevant given your assessment and the patent clause seems overly complex if all they are saying that any patents that are infringed upon by the contribution that are owned by the contributor must be licensed royalty free for all users of said code. The level of protection for end users seems laughable to me, since there are still so many holes open for evil doers aka patent trolls can exploit. So I guess CLA are only a major annoyance and placebo. The reason why they are so complicated is because they were written by lawyers. If they made contracts in such a way that mere mortals understand them, the wouldn't be able to afford fast cars and big houses. Sounds to me like we should stop accepting this legal BS. Then they will only be able to pay for a nice little house if they write understandable stuff or nothing is they are unwilling to adapt to the demands of their customers. The copyright part is not irrelevant. It is different from country to country. The copyright itself is transferrable in, for example, the Netherlands and the United States, but not in Germany, Austria or Switzerland. Most CLAs out there used by open source projects are derived from the Apache Foundation CLA, which originates from the U.S. The legal text does not seem to take any effort to bridge these differences, instead focusing solely on US law. And CLAs actually _do_ provide reasonable protection. The idea is that someone cannot sneak in code he has patents on, and later ask for royalty fees. Same goes for people who contribute in goodwill, but once the project is popular and successful, want a slice of the pie for themselves. Or companies that allow their devs to contribute to an open source project, then a new manager decides that the company holds patents on the contributions and now wants money for it. It protects everybody, and harms nobody (unless you have something against granting rights to the project you're contributing to). Again, I have no issue signing over copyright, even though this does not apply to my country of origin. I also do not have a problem with signing over licenses for patents I or my employer may hold that my be infringed upon by my contributions. But in order for me to sign something, it needs to be understandable. More importantly for the bulk of the project to be able to sign stuff like this is needs to be really easy for legal departments to ok the terms. The Apache CLA imho does not fit this criteria, though I do appreciate that there is some level of standardization around the Apache CLA. Anyways, I guess we have discussed the topic sufficiently given that we do not have a final version for the PDO2 CLA or a proper lawyer to give advice. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
Alexey Zakhlestin wrote: isn't "public domain" specific enough? Public Domain actually isn't a universal concept, and it isn't recognized everywhere in law. A very open BSD style license first, followed by granting it to the public domain, should cover all bases. Even somewhere that doesn't recognize public domain should fail over to accept your BSD license. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
Hello Solar, thanks again for offering this. What we require is to have the PHP License in the code. If you are fine with this we will gladly replace the existing code with yours. You can of course put more header information in there to stress out further that it is your code and where it can be found. The key is that we indeed try to get rid of anything that is not under the PHP License. marcus Sunday, December 9, 2007, 2:05:52 AM, you wrote: > 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, Best regards, Marcus -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Maybe a problem? undetected name clash makes static method unaccessible through outside static reference
Greg Beaver schreef:
> Martin Alterisio wrote:
>> Consider the following code:
>>
>> foo.php:
>> > class test {
>> public static function foo() { echo "I'm foo in class test\n"; }
>> public static function foo2() { self::foo(); }
>> }
>> ?>
>>
>> foo2.php:
>> > namespace test;
>> function foo() { echo "I'm foo in namespace test\n"; }
>> ?>
>>
>> test.php:
>> > include 'foo.php';
>> include 'foo2.php';
>> test::foo(); // I'm foo in namespace test
>> use test::foo as dummy;
>> test::foo(); // I'm foo in namespace test
>> test::foo2(); // I'm foo in class test
>> $test = 'test';
>> $test::foo(); // I'm foo in class test
>> call_user_func(array('test', 'foo')); // I'm foo in class test
>> ?>
>>
>> Please review the following observations:
>>
>> There's a name clash that goes undetected: test::foo refers to both a
>> namespaced function and a static method.
>>
>> Once the clash occur there's no way to refer to the static method through a
>> static reference, except when within the class scope where you can refer to
>> the method through self::
>> The static method remains partially hidden by the namespaced function.
>
> Don't forget about ::test::foo() which refers to class test, method
> foo(). However, this is an issue, and one of the main reasons I dislike
> putting functions and constants in namespaces, as this ends up sort of
> like OO without inheritance and confuses the issue of static methods as
> you pointed out.
>
> However, having said that, in my experience, developers either use
> functions or OO, very rarely mixing the two on an extensive basis, and
> so name collisions become much less likely between static methods and
> namespaced functions.
why exactly should we need to have this ambiguity and possible naming collision?
I thought namespaces are about avoiding naming collisions?
>
> Greg
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
isn't "public domain" specific enough? On 12/21/07, Martin Alterisio <[EMAIL PROTECTED]> wrote: > 2007/12/20, Stanislav Malyshev <[EMAIL PROTECTED]>: > > > > > 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/ > > > > Tried that one and it is about 30% faster indeed (on md5-only benchmark, > > 32-bit Linux on AMD Opteron. Anybody objects to accepting this? > > > > > Just one, but is a mere formality. I didn't see any copyright notice on the > code nor a licensing document attached. I have not much of the legal > mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't external > code that's to be included in the php codebase meet these legal formalities > so it doesn't become a liability? > > That's all. > > Best Regards, > > Martin Alterisio > > PS: Does anyone knows if using a nickname for authorship is considered > legally valid? I believe it might be valid, think about writers that use > such pseudonyms, but I'm not sure... > -- Alexey Zakhlestin http://blog.milkfarmsoft.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] faster & public domain MD5 implementation
On 21.12.2007 05:15, Martin Alterisio wrote: >> http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/popa3d/popa3d/md5/ >> >> Tried that one and it is about 30% faster indeed (on md5-only benchmark, >> 32-bit Linux on AMD Opteron. Anybody objects to accepting this? >> >> > Just one, but is a mere formality. I didn't see any copyright notice on the > code nor a licensing document attached. I have not much of the legal > mumbo-jumbo comprehension, so, correct me if I'm wrong, shouldn't external > code that's to be included in the php codebase meet these legal formalities > so it doesn't become a liability? Good point, the license should be explicitly specified. I'm going to test the patch on Linux/64bit today. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP-CVS] cvs: CVSROOT / avail loginfo
Am 20.12.2007 um 23:43 schrieb Lukas Kahwe Smith: On 20.12.2007, at 20:54, David Zülke wrote: Am 20.12.2007 um 19:25 schrieb Lukas Kahwe Smith: So maybe enlighten me what the purpose of the CLA is. The purpose is that a project/company/whoever has written confirmation that the developer who contributes something gives the respective entity full permission and license on copyright and, should he own any that cover the contribution, patents. My understand is that with all contributions done under a CLA it becomes fairly easy for all users of the code to simply point anyone sueing to the relevant contributor. The given code can be replaced and life goes on except for the contributor. Without a CLA is becomes much harder for the various users to pull their head out of things as easily, which means they will have a much greater interest in getting the case dismissed entirely. No, that is not correct. With and without a CLA, the contributor who commits something on which Foo, Inc. holds a patent, is the originator of the patent breach. A CLA does not change that, nor protect from that. The patent holder can, with and without the CLA, still sue both you and the project you made the contribution to. I wonder why they need such elaborate bla bla to just say so trivial things. The copyright part seems irrelevant given your assessment and the patent clause seems overly complex if all they are saying that any patents that are infringed upon by the contribution that are owned by the contributor must be licensed royalty free for all users of said code. The level of protection for end users seems laughable to me, since there are still so many holes open for evil doers aka patent trolls can exploit. So I guess CLA are only a major annoyance and placebo. The reason why they are so complicated is because they were written by lawyers. If they made contracts in such a way that mere mortals understand them, the wouldn't be able to afford fast cars and big houses. The copyright part is not irrelevant. It is different from country to country. The copyright itself is transferrable in, for example, the Netherlands and the United States, but not in Germany, Austria or Switzerland. Most CLAs out there used by open source projects are derived from the Apache Foundation CLA, which originates from the U.S. And CLAs actually _do_ provide reasonable protection. The idea is that someone cannot sneak in code he has patents on, and later ask for royalty fees. Same goes for people who contribute in goodwill, but once the project is popular and successful, want a slice of the pie for themselves. Or companies that allow their devs to contribute to an open source project, then a new manager decides that the company holds patents on the contributions and now wants money for it. It protects everybody, and harms nobody (unless you have something against granting rights to the project you're contributing to). Hope that helps understand the matter a bit better. David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: free_man
On 21.12.2007 06:35, sungyun wrote: > Developing the PHP runtime > Translating the documentation Usually we don't give CVS accounts right away. It's recommended to start with sending patches to the appropriate lists. -- Wbr, Antony Dovgal -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
