# I think that "Function naming inconsistency" bug deservers more attention - Thread: https://externals.io/message/65166 - Original archive: https://news-web.php.net/php.internals/65166 - Started by turneliusz@gmail.com on 2013-01-25T14:24:12+00:00 - Messages: 34 - Page 1 of 2: messages 1 to 25 (25 per page, add `?page=N` to the URL) - Next page: https://externals.io/message/65166.md?page=2 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #65166 — turneliusz@gmail.com — 2013-01-25T14:24:12+00:00 URL: https://externals.io/message/65166#65166 I've seen discussion on reddit http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ where many people are surprised why PHP can't have this done. Why inconsistency is something that we want to keep because of backward compatibility. PHP already introduced many backward compatibility issues and this change could just be fixed in old PHP projects (prior to for example PHP 6 or PHP 5.5) by just simple "find & replace" script in really most of the cases. Why it is so hard to deprecate functions that uses naming convention that dosen't really exist, that names were created by some crazy "let's imagine some name and don't look at API we have" man? Why we can't have PHP 6 that will be not some amazingly featured-packed version but version with API that just... makes sense. Regards, Damian Tylczyński --- ## #65167 — Martin Keckeis — 2013-01-25T14:37:29+00:00 URL: https://externals.io/message/65166#65167 · In reply to: #65166 Hello, you are right Damian. Also today on a german page: http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html Relating to this bug report: https://bugs.php.net/bug.php?id=52424 Best regards Martin --- ## #65168 — Pierre Joye — 2013-01-25T15:00:24+00:00 URL: https://externals.io/message/65166#65168 · In reply to: #65167 hi, On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis wrote: > Hello, > > you are right Damian. > > Also today on a german page: > http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html > > Relating to this bug report: > https://bugs.php.net/bug.php?id=52424 We all know that, since years. The answer however remains the same: We can't do it without major backward compatibility breakages. Please check the internals archive for the past discussions. Cheers, -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- ## #65170 — Sebastian Krebs — 2013-01-25T15:56:52+00:00 URL: https://externals.io/message/65166#65170 · In reply to: #65168 2013/1/25 Pierre Joye > hi, > > On Fri, Jan 25, 2013 at 3:37 PM, Martin Keckeis > wrote: > > […] > http://it-republik.de/php/news/Machen-wir-das-Namensschema-der-PHP-Funktionen-einheitlich%21-066539.html > > […] > > We all know that, since years. The answer however remains the same: We > can't do it without major backward compatibility breakages. Please > check the internals archive for the past discussions. > Theoretically you can have both: The API in it's current state as well as a consistent api in the "php"-namespace. > > Cheers, > -- > Pierre > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > -- > > > > -- github.com/KingCrunch --- ## #65181 — Stas Malyshev — 2013-01-25T18:41:31+00:00 URL: https://externals.io/message/65166#65181 · In reply to: #65166 Hi! > I've seen discussion on reddit > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > where many people are surprised why PHP can't have this done. Why > inconsistency is something that we want to keep because of backward > compatibility. PHP already introduced many backward compatibility I don't think you can just hand-wave the issue away by saying "PHP introduced BC breaks". First, PHP practically never introduced BC breaks that breaks almost all existing code. Even when we did huge changes - like OO model change - we had compatibility mode for a long time, and that considering in most scenarios it still worked the same. BC breaks happened, but they mattered only in some specific scenarios and usually this was done because old way of doing it could no longer be practically used or lead to bigger problems than BC (such as security issues or frequent hard-to-find bugs). Second, here we have breakage that would happen just for the sake of satisfying some people that thing having or not having underscore in function name really matters. For 99% of people out there, it does not. I agree it'd be nice if we came back in time and wrote function naming standard before PHP functions were implemented. But since we can't go back in time, we have to choose between things that matter to most of people - e.g., compatibility and code that keeps working when upgrading to next PHP version - against naming beauty that doesn't matter for most of them. I agree that beautiful is better than ugly. But, ugly but working is better than beautiful but broken. > names were created by some crazy "let's imagine some name and don't > look at API we have" man? Why we can't have PHP 6 that will be not > some amazingly featured-packed version but version with API that > just... makes sense. Because there would be zero incentive to upgrade to it for any current user. You'd have to rewrite and retest your code with zero benefit. And you'd have to maintain two codebases from now on for any application that is supposed to run on both, or resort to all kinds of trickery to keep it working. As someone working with 600K+ LOC code base, I don't see doing that as something I'm eagerly waiting for. Then the question is - why would we release a version that 99% of existing users would hate to use? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #65187 — Seva Lapsha — 2013-01-25T18:55:23+00:00 URL: https://externals.io/message/65166#65187 · In reply to: #65181 Well, how about renaming the functions, create aliases for BC and throw `E_DEPRECATED` or `E_STRICT` on their usage? And write a PEAR script bundled with the distribution to migrate to the new convention? On Fri, Jan 25, 2013 at 1:41 PM, Stas Malyshev wrote: > Hi! > > > […] > http://www.reddit.com/r/PHP/comments/174qng/lets_make_phps_function_names_consistent/ > > […] > > I don't think you can just hand-wave the issue away by saying "PHP > introduced BC breaks". First, PHP practically never introduced BC breaks > that breaks almost all existing code. Even when we did huge changes - > like OO model change - we had compatibility mode for a long time, and > that considering in most scenarios it still worked the same. BC breaks > happened, but they mattered only in some specific scenarios and usually > this was done because old way of doing it could no longer be practically > used or lead to bigger problems than BC (such as security issues or > frequent hard-to-find bugs). > > Second, here we have breakage that would happen just for the sake of > satisfying some people that thing having or not having underscore in > function name really matters. For 99% of people out there, it does not. > I agree it'd be nice if we came back in time and wrote function naming > standard before PHP functions were implemented. But since we can't go > back in time, we have to choose between things that matter to most of > people - e.g., compatibility and code that keeps working when upgrading > to next PHP version - against naming beauty that doesn't matter for most > of them. I agree that beautiful is better than ugly. But, ugly but > working is better than beautiful but broken. > > > […] > > Because there would be zero incentive to upgrade to it for any current > user. You'd have to rewrite and retest your code with zero benefit. And > you'd have to maintain two codebases from now on for any application > that is supposed to run on both, or resort to all kinds of trickery to > keep it working. As someone working with 600K+ LOC code base, I don't > see doing that as something I'm eagerly waiting for. Then the question > is - why would we release a version that 99% of existing users would > hate to use? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #65189 — Rasmus Lerdorf — 2013-01-25T19:04:51+00:00 URL: https://externals.io/message/65166#65189 · In reply to: #65187 > Well, how about renaming the functions, create aliases for BC and throw > `E_DEPRECATED` or `E_STRICT` on their usage? And write a PEAR script bundled > with the distribution to migrate to the new convention? Throwing warnings on perfectly working code is really a bad idea. It annoys users, slows down their code, and doesn't add any value at all to them. It should also be noted that many of the function names that people don't think are consistent are actually quite consistent when you consider that PHP is just a thin wrapper on top of underlying libraries. Functions from libc like `tempnam()` and `strlen()` are perfectly fine. The fact that you can go to your Linux command line and type: "man tempnam" to get a good idea of what is happening behind the scenes of the PHP function of the same name is a good thing. -Rasmus --- ## #65192 — turneliusz@gmail.com — 2013-01-25T19:24:33+00:00 URL: https://externals.io/message/65166#65192 · In reply to: #65189 Yes, it's extremely useful, especially because most of the php developers are developing under Linux and most of them are coming from C and many other languages. Give ma a break... Second thing, we're afraid of throwing deprecated errors. Let's see the case. On production machines there are errors hidden from the users (display errors: none or just strict, notice, deprecated types hidden), experienced developers when they will not like them during development will disable them or migrate their code, new developers will just learn new API. Where is the problem? I'm not talking about removing some functions but just deprecating them to to get some time and simply to be ready to improve the PHP as a language in the future when time will come. 25 sty 2013 20:04, "Rasmus Lerdorf" napisał(a): > > > […] > > Throwing warnings on perfectly working code is really a bad idea. It > annoys users, slows down their code, and doesn't add any value at all to > them. > > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like `tempnam()` and `strlen()` are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > > -Rasmus --- ## #65193 — Seva Lapsha — 2013-01-25T19:25:07+00:00 URL: https://externals.io/message/65166#65193 · In reply to: #65189 > > > […] > > Throwing warnings on perfectly working code is really a bad idea. It could be a new type of notice then, which could be controlled by configuration. > It annoys users, The configuration could be turned off by default. > slows down their code, Isn't it a flaw of the current implementation of throwing messages, which could be improved? AFAIU, if suppressed warnings would not be processed as the active ones, the performance effect would be negligible to zero. > and doesn't add any value at all to them. > It would add the value to those who care. > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like `tempnam()` and `strlen()` are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > True. Don't get me wrong, I personally don't mind using the good old names, even typos in the names have their own charm. I just think that the point of view of order-freaks could be respected a little after all these years of complaints, so I'm trying to find a compromise and more PHP users would be happy. :) > > -Rasmus --- ## #65196 — Stas Malyshev — 2013-01-26T01:02:52+00:00 URL: https://externals.io/message/65166#65196 · In reply to: #65187 Hi! > Well, how about renaming the functions, create aliases for BC and throw > `E_DEPRECATED` or `E_STRICT` on their usage? And write a PEAR script bundled > with the distribution to migrate to the new convention? Well, the problem with these things is this: suppose you have testing suite that verifies your code. What you do with E_DEPRECATED? You can treat them as failure, and that means in hypothetical PHP 6 release you code is broken, and you can't release it until you fixed it - so that means for you the effect it as if the function was effectively removed. On the other hand, you can ignore it - and then when these functions are removed, you get all your code broken, and while it is not removed, it's like we didn't do anything. The purpose of deprecation is to give you time to upgrade your code, but the question here is - why would you want to change your perfectly working code, if there would be no benefit to you but couple of underscored placed here and there so people could feel better knowing every function has underscore in the same place? As I said, while it's nice, I don't think it is worth it. When the change is necessary - e.g., when we have API that is flawed or unsafe, take the recent example of CURL file uploading API, which exposes tricky security issues - then deprecation/removal may be warranted, because your code, that you think is working, might in fact have security hole. So we find that avoiding security hole is more important. But I personally do not see how adding underscores is as important. If somebody came forward and proposed better API - that could exist in parallel with current one, but eventually replace it if people like it so much nobody would use the old one anymore - it could be discussed. But just shuffling couple of underscores here and there - really, I don't see how it is worth the trouble. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #65197 — Clint Priest — 2013-01-26T02:03:14+00:00 URL: https://externals.io/message/65166#65197 · In reply to: #65196 > Hi! > > > […] > Well, the problem with these things is this: suppose you have testing > suite that verifies your code. What you do with E_DEPRECATED? You can > treat them as failure, and that means in hypothetical PHP 6 release you > code is broken, and you can't release it until you fixed it - so that > means for you the effect it as if the function was effectively removed. > On the other hand, you can ignore it - and then when these functions are > removed, you get all your code broken, and while it is not removed, it's > like we didn't do anything. > Depending on just what is going to change, a simple script people can run to scan their code and spit out a diff of recommended changes they can simply review and approve of could be pretty painless. Then again you probably have people that would be subject to vendor updates without the ability to run the script or understand the changes it recommends. May be a small minority though. Are we talking mostly needle/haystack & haystack/needle type BC changes here or other more nefarious things? Realistically couldn't we just introduce a configuration parameter to keep "the inconsistent parameter order," perhaps along with a script to suggest the changes needed to bring some code up to speed? Would be a bit more in the core, for a time, but would allow people to transition when they wanted to, without all of the errors... -- -Clint --- ## #65198 — Stas Malyshev — 2013-01-26T02:43:25+00:00 URL: https://externals.io/message/65166#65198 · In reply to: #65197 Hi! > Realistically couldn't we just introduce a configuration parameter to > keep "the inconsistent parameter order," perhaps along with a script to > suggest the changes needed to bring some code up to speed? People think that "introduce a configuration parameter" is a solution to almost any BC problem in the engine. It's not true, actually it's the opposite - now you have to maintain two code bases, one for one value of the parameter and one for another. Now imagine there's 10 such parameters, for different things in PHP, and you get 1024 options to test you application on. That's why we try to reduce behavior-modifying options to a minimum. Config options are for configuration, not for changing engine behavior in BC-breaking way. That's one of the reasons why magic_* were not a good idea and we had to get rid of them. And imagine integrating a library that is written with one set of engine options into application that expects another set of options. Now imagine application that uses a dozen of third-party libraries (in current open-source world, it's not too many at all), each of them expecting its own set of engine-modifying options. It would very quickly become a complete nightmare. So I think we should try to keep PHP behavior unified and avoid behavior-modifying switches as much as possible. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 --- ## #65199 — Clint Priest — 2013-01-26T03:01:49+00:00 URL: https://externals.io/message/65166#65199 · In reply to: #65198 > Hi! > > > […] > People think that "introduce a configuration parameter" is a solution to > almost any BC problem in the engine. It's not true, actually it's the > opposite - now you have to maintain two code bases, one for one value of > the parameter and one for another. Now imagine there's 10 such > parameters, for different things in PHP, and you get 1024 options to > test you application on. That's why we try to reduce behavior-modifying > options to a minimum. Config options are for configuration, not for > changing engine behavior in BC-breaking way. That's one of the reasons > why magic_* were not a good idea and we had to get rid of them. > > And imagine integrating a library that is written with one set of engine > options into application that expects another set of options. Now > imagine application that uses a dozen of third-party libraries (in > current open-source world, it's not too many at all), each of them > expecting its own set of engine-modifying options. It would very quickly > become a complete nightmare. > > So I think we should try to keep PHP behavior unified and avoid > behavior-modifying switches as much as possible. I agree all of that would suck, but would it suck less than the alternatives for the most people involved? -- -Clint --- ## #65200 — Ronald Chmara — 2013-01-26T03:59:05+00:00 URL: https://externals.io/message/65166#65200 · In reply to: #65189 Here I am, ten years later, and the same issue is being rehashed just as it was when it was brought up ten years ago. Over those ten years, things have slowly gotten better, but the underlying issue remains the same. PHP is glue. PHP has not taken the path of re-naming everything to conform to a new "PHP standard", other than underscores, and attempts at function prefixes. Sure, we could start adding aliases like libc_strlen(), and maybe that's worth a thought, but its adding another layer of complexity, to achieve simplicity. > > > […] > > Throwing warnings on perfectly working code is really a bad idea. It > annoys users, slows down their code, and doesn't add any value at all to > them. > > It should also be noted that many of the function names that people > don't think are consistent are actually quite consistent when you > consider that PHP is just a thin wrapper on top of underlying libraries. > Functions from libc like `tempnam()` and `strlen()` are perfectly fine. The > fact that you can go to your Linux command line and type: "man tempnam" > to get a good idea of what is happening behind the scenes of the PHP > function of the same name is a good thing. > > -Rasmus --- ## #65201 — Lester Caine — 2013-01-26T06:24:29+00:00 URL: https://externals.io/message/65166#65201 · In reply to: #65199 Clint Priest wrote: > > […] > I agree all of that would suck, but would it suck less than the alternatives for > the most people involved? `E_STRICT` is bad enough and is one of the switches you would have to test everything against. But the main problem is that there is nothing in the historic code base that easily allows someone to identify which version of PHP IS required to run it? THIS is where move code forward to comply with the existing 'E_DEPRECATED/E_STRICT' is a minefield, so adding yet another major rework seems to be a step too far? Now if someone could come up with a third party tool that reads an application ... identifies all of the problems ... and at least offer pointers to fix them ... -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk --- ## #65202 — Kris Craig — 2013-01-26T06:37:05+00:00 URL: https://externals.io/message/65166#65202 · In reply to: #65201 > Now if someone could come up with a third party tool that reads an > application ... identifies all of the problems ... and at least offer > pointers to fix them ... I like that idea! Kinda surprised something like that doesn't already exist, actually.... --Kris --- ## #65203 — Thomas Bley — 2013-01-26T07:05:27+00:00 URL: https://externals.io/message/65166#65203 · In reply to: #65198 1) What about using a new open tag? pos("lo")) {... echo $s->htmlSpecialChars(); echo $s->convert("ISO-8859-1"); $a = new Array([1,2,3]); if ($a->contains(1)) {... Regards, Thomas > Hi! > > > […] > > People think that "introduce a configuration parameter" is a solution to > almost any BC problem in the engine. It's not true, actually it's the > opposite - now you have to maintain two code bases, one for one value of > the parameter and one for another. Now imagine there's 10 such > parameters, for different things in PHP, and you get 1024 options to > test you application on. That's why we try to reduce behavior-modifying > options to a minimum. Config options are for configuration, not for > changing engine behavior in BC-breaking way. That's one of the reasons > why magic_* were not a good idea and we had to get rid of them. > > And imagine integrating a library that is written with one set of engine > options into application that expects another set of options. Now > imagine application that uses a dozen of third-party libraries (in > current open-source world, it's not too many at all), each of them > expecting its own set of engine-modifying options. It would very quickly > become a complete nightmare. > > So I think we should try to keep PHP behavior unified and avoid > behavior-modifying switches as much as possible. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 --- ## #65206 — Rasmus Lerdorf — 2013-01-26T08:57:57+00:00 URL: https://externals.io/message/65166#65206 · In reply to: #65203 Please stop with these. We can't keep explaining why function aliases, Please stop with these. We can't keep explaining why function aliases, > 20 years is a bad idea. > > There is a reason that REFERER is still around in HTTP. It is obviously > not spelled correctly, but the pain of fixing it would far outweigh the > appeasement of the pedants out there. Does it make it harder to figure > out HTTP-related stuff? Not really, you won't necessarily know this term > even exists until you learn about it. Same goes for PHP functions. If > you understand where they come from you expect them to be named strlen, > strchr, strpos, etc. and if you don't understand their origin then you > simply learn them or let your IDE autocomplete them for you. > > And if you really think this is something a majority of people are > interested in, write up an RFC and put it to a vote. And when that fails > write yourself a userspace "consistency" library that names all the > functions the way you feel would make them consistent and put it out > there. or heck, if you are worried about performance of a userspace > wrapper, write an extension that does it. But please stop posting about > it on internals. There are a lot of real issues we should be spending > cycles on. > I don't think this could have been phrased any better :) *tip of the hat* > > -Rasmus --- ## #65208 — Thomas Bley — 2013-01-26T09:18:29+00:00 URL: https://externals.io/message/65166#65208 · In reply to: #65206 So function aliases, new open tag and deprecation are bad. What about the String class? I think there was some "Let's ... start exploring lighter and more approachable ways to attack Unicode" on internals ... Regards, Thomas > Please stop with these. We can't keep explaining why function aliases, > 20 years is a bad idea. > > There is a reason that REFERER is still around in HTTP. It is obviously > not spelled correctly, but the pain of fixing it would far outweigh the > appeasement of the pedants out there. Does it make it harder to figure > out HTTP-related stuff? Not really, you won't necessarily know this term > even exists until you learn about it. Same goes for PHP functions. If > you understand where they come from you expect them to be named strlen, > strchr, strpos, etc. and if you don't understand their origin then you > simply learn them or let your IDE autocomplete them for you. > > And if you really think this is something a majority of people are > interested in, write up an RFC and put it to a vote. And when that fails > write yourself a userspace "consistency" library that names all the > functions the way you feel would make them consistent and put it out > there. or heck, if you are worried about performance of a userspace > wrapper, write an extension that does it. But please stop posting about > it on internals. There are a lot of real issues we should be spending > cycles on. > > -Rasmus --- ## #65210 — Pierre Joye — 2013-01-26T10:45:33+00:00 URL: https://externals.io/message/65166#65210 · In reply to: #65208 hi, > So function aliases, new open tag and deprecation are bad. What about > the String class? > I think there was some "Let's ... start exploring lighter and more > approachable ways to attack Unicode" on internals ... Unicode is a totally different topic. I would suggest to look at intl (ICU) extension for a start. Also about cleanup the APIs, take a look at this prototype: https://github.com/nikic/scalar_objects This is something that would be much cleaner and without BC problems. Cheers, -- Pierre @pierrejoye --- ## #65211 — turneliusz@gmail.com — 2013-01-26T11:34:37+00:00 URL: https://externals.io/message/65166#65211 · In reply to: #65210 I really like the idea 2013/1/26 Pierre Joye : > hi, > > > > […] > > Unicode is a totally different topic. I would suggest to look at intl > (ICU) extension for a start. > > Also about cleanup the APIs, take a look at this prototype: > > https://github.com/nikic/scalar_objects > > This is something that would be much cleaner and without BC problems. > > Cheers, > -- > Pierre > > @pierrejoye --- ## #65212 — Thomas Bley — 2013-01-26T11:37:23+00:00 URL: https://externals.io/message/65166#65212 · In reply to: #65210 > https://github.com/nikic/scalar_objects I think register_primitive_type_handler() is too exclusive: When I use 2 frameworks in the same code base, one might do register_primitive_type_handler('string', 'A\StringHandler') and the other might do register_primitive_type_handler('string', 'B\StringHandler') in the bootstrap. The result will be only the second one is working. Also I see more variations instead of a cleanup. Working with an IDE, register_primitive_type_handler requires type hints to use auto completion: register_primitive_type_handler('string', 'StringHandler'); /* @var $str StringHandler */ $str = 'foobar'; echo $str->length(); vs. $str = new StringHandler('foobar'); echo $str->length(); Regards, Thomas > hi, > > > > […] > > Unicode is a totally different topic. I would suggest to look at intl > (ICU) extension for a start. > > Also about cleanup the APIs, take a look at this prototype: > > https://github.com/nikic/scalar_objects > > This is something that would be much cleaner and without BC problems. > > Cheers, > -- > Pierre > > @pierrejoye --- ## #65213 — inefedor@gmail.com — 2013-01-26T11:48:20+00:00 URL: https://externals.io/message/65166#65213 · In reply to: #65212 > I think register_primitive_type_handler() is too exclusive: Hi Thomas, as @nikic noted in the description, it's just a proof of concept. --- ## #65214 — Pierre Joye — 2013-01-26T11:50:31+00:00 URL: https://externals.io/message/65166#65214 · In reply to: #65212 hi, > > […] > > I think register_primitive_type_handler() is too exclusive: The point of this prototype is to define what is the best APIs we can create to solve the "inconsistencies"/clean the current API. This specific function is only a helper here, I do not see it being implemented core. -- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org --- Next page: https://externals.io/message/65166.md?page=2