Re: [PHP-DEV] Older style frameworks ...
..snip Robert ... The main problem with the PHP5.3/4 changes are that the attitude with PHP5.3 was 'you don't have to worry', but very quickly that became 'now you do' simply by the switch of the default on e_strict. Perhaps when every existing project is totally e_strict complaint things can be different, but the amount of work needed to be carried out is simply not being achieved, so we have to decide if we want to spend time fixing things like PEAR - my own patches for which I've recently published - or simply switch off the problem and disable e_strict? I know I've been banging on about this for a long time - but I'm still trying to update my own and other peoples code to work cleanly today :( It would be nice to see a few more people helping ... rather than simply complaining at my moaning ... PHP created the problems 'full stop' Ok, I believe your views have been expressed clearly and for the sanity of the mailing-list I'd consider stopping this thread. I would however suggest that you create an RFC which outlines exactly what you'd like to change and how you'd like to see it change and from there, a vote will ensue. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Some Stats
Great work everyone :) On 17 April 2012 12:44, David Soria Parra d...@php.net wrote: On 2012-04-17, Rasmus Lerdorf ras...@lerdorf.com wrote: Number of posts to the commit list since Jan.1,2012 (top 25): Number of commits to php-src (excluding merges) since Jan.1,2012 (top 15): 126 Xinchen Hui 83 Rasmus Lerdorf 79 Gustavo Andre dos Santos Lopes 73 Pierre Joye 62 Anatoliy Belsky 53 Stanislav Malyshev 46 Dmitry Stogov 45 Christopher Jones 36 Johannes Schlueter 32 Michael Wallner 29 Ilia Alshanetsky 28 Nikita Popov 17 Nuno Lopes 15 Derick Rethans 14 David Soria Parra -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SplClassLoader RFC Voting phase
Hey everyone, After lengthy discussions and various opinion, we believe this issue has been discussed at length and the PSR-0 has had this standard effective for the past 1.5 year. The SplClassLoader RFC has moved to voting stage. Please cast your votes at https://wiki.php.net/rfc/splclassloader/vote Thank you very much for all the interest showed so far, -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
On 24 October 2011 16:53, Paul Dragoonis dragoo...@gmail.com wrote: On Mon, Oct 24, 2011 at 3:47 PM, guilhermebla...@gmail.com guilhermebla...@gmail.com wrote: Hi internals, It's been a while since Stas accepted that, but it seems the class haven't been merged since then. What's the status of this? Can I expect SplClassLoader in 5.4.0? It seems it was approved, but wasn't merged and thread was lost in space. =( There's an RFC for it: https://wiki.php.net/rfc/splclassloader There's a patch for it: https://github.com/metagoto/splclassloader If we can identify where we want it in the structure of the PHP project, I'll be happy to merge the implementation and modify the config files to have --enable-spl-autoloader or such. Does anyone have a preference for this? /ext/spl/ /ext/spl-loader/ /ext/spl-autoloader/ -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
What are peoples' thoughts on the name of the class? The word auto fits best with all that has come before, yet the proposal here uses class: what about SplAutoloader? With the introduction of this new class, whatever the name, what happens to __autoload() and spl_autoload_register(), if anything? How many ways do we want/need to load a class? I believe by calling a class SplAutoloader when there is already an implementation of spl_autoload that does something very different it would be advised to not name it of the same sort... this is what people would start to think about. The name SplClassLoader is much more specific. If we needed to keep the word Auto it would seem better named SplClassAutoLoader. spl_autoload is completely separate from __autoload today. Also __autoload does differ from the spl_autoload facility in several ways and is not recommended even from the manual standpoint: www.php.net/autoload. Secondarily; a class loader cannot autoload functions - it is made to only implement PSR-0 and nothing more. While you may use spl_autoload to load classes the implementation can also load in functions. This class is really just enforcing a specific standardization. I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
I've started toying around with adjusting the patch. A bit of rewrite is required but I'm attempting to modify the patch to be included directly in SPL with the name SplClassLoader so that one can do: $cl = new \SplClassLoader(..., ...); Once the patch is adjusted to fit with SPL, we can revisit the name however it is going to be used. For the record: https://gist.github.com/1310352 (I know there are Whitespaces issues, I'll get those resolved) I'll be adding the tests tomorrow morning and then making sure the RFC is adjusted. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplClassLoader
Could you open a FR at bugs.php.net and attach the patch to it please? Could be easier to track (and the # to the RFC too :) Yeah I'll do that once I have the tests adjusted and once I know the patch actually works as expected. -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
On 13 June 2011 09:06, Ifthikhan Nazeem iftecan2...@gmail.com wrote: Sounds like a great idea. I have always wanted to contribute but did not find a structured way to incrementally build my knowledge of the internals. This might be a great way to attract new devs. Hey everyone, thanks for the interest in participating as mentees. Just to give you an update, right now I'm trying to compile a list of volunteer-mentors. Once this has been done, we'll start compiling user-groups mentees and mentees in general. Thanks for your interest :) -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
See response inline. As I have nothing against a mentor program, nor something in favor of one, I think it should be done right from the 1st day. And to be in right it has to be open, by all means. Restricted lists, private discussions, etc. have no place in OSS projects. If you don't have access to the wiki to document your progress, pls request an account. If anything is happening or happens, it should happen in the respective list (doc, web, internals, pecl) and publicly. Thanks for that and we aren't talking about a restricted list but a different mailing list where newcomers could browse freely and ask all sorts of questions that might or might not have their place on the internals list. Moreover, before spending time creating all the pages, I'm validating the idea by talking to people and trying to get things going. If an interest is shown, I'll be glad to create any wiki page you want me to create however, until the idea is validated, I'm not going to create a ghost-wiki page that might end up dieing. My doubts are more (like this thread shows) about the lack of will to contribute (to wish something is not necessary a will). Mentors does not or cannot create extra time in contributors days either :). To guide the contributors through the php project is only a very small part of the actual work, and could be explain better in our docs/wiki/sites. Agreed. One immediate step could be to create a 'contribute' page, www.php.net/contribute. This page should explain the various areas one could contribute (docs, tests, core, pecl, etc.) and how to get in touch with the responsible developers. Maybe with a link to an issue in the bug tracker for a given todo, or in a wiki doc (for a verbose description). See Pierre, that's where I believe we are doing things wrong. We already have all our infrastructure to report bugs, create wiki pages, send emails. The goal of the program is to create something more personal, something more interactive than just sending everyone to read the manual. I do however agree that we need to have some initial steps created (ala contribute page you suggested). Sure some contributors might not have extra time in their day and that's exactly why I precisely mentioned [IDEA] in the subject. Before going on a mad documentation trip, I want to see who's interested in contributing. I've received a bunch of emails from people that want to help with the core but without volunteer-mentors, there's only so much that can be done (links to the wiki, docs, books to read etc.). The idea behind this whole thing Pierre is not to attack anyone or to denigrate the work of the core team but rather to help our various communities talk together. By various communities, I mean from core devs to wordpress developers. There are a lot of developers out there that have never even been remotely interested in contributing to PHP because of the tedious process of learning how to write Zend-C. Either way, I think you are right and this needs to be open. Before time is invested into making this properly opened, I'd like to validate the idea. If anyone is interested in starting a few contributing pages on the wiki and whatnot then nothing stops them or you from doing it. It is open source, let ideas flourish. Back to the main subject of discussion: Are you interested in being a volunteer-mentor? -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [IDEA/PRE-RFC] PHP Core Mentorship Program
Hey all, Let me start by saying that this is merely an idea I'm trying to put together and before doing so, I need to see who would be interested. A short while ago, the Python community created something called The Python Core Mentorship Program [1][2] which is essentially an attempt to lower the barrier of entry to the Python core for new developers, students, etc. and connect everyone together in a more cohesive manner where people actually talk and interact. I strongly believe in such initiative and believe this is something we should also think about. Simply put, I'd love to put something together for the PHP core/internals where the goals of the program would be, not unlike the Python project, to get a few internals (Zend Contribs (Stas are you reading this? :P), Core contribs, PECL extensions developers, documentation maintainers) to be willing to help newcomers and provide a more comprehensive understanding of the contribution processes, internal trickeries, optimisations, etc. The general idea is to create a channel between the rest of the world and the internals of PHP where more experienced developers can transfer their knowledge and get a fresh perspectives from new developers that haven't approached the core before. Before continuing further into exploring this idea, we need to get volunteer mentors. The mentee process is likely to get a self-managed one and the mentors' role will hopefully be rather low in terms of time consumptions and the roles of the mentor will most likely be: - Introducing new developers to the processes - Answering questions - Helping with code review of patches Again, like the Python program and similarly to the GSOC projects, we should have a mailing list (restricted) dedicated only to the mentor (php-mentorship?) where anyone can ask the simpler questions. From this mailing list we should also be able to construct a solid baseline for new developers contributing to PHP. From the mailing list, we'll see what questions are coming over and over again we'll be able to build a wiki-faq-like sections for new contributors. I digress and here's what I'm hoping to achieve with this email: I want to get a few contributors from various aspects of the core including docs and pecl extensions willing to help new people. If you are interested, please raise your voice and if enough interest is displayed I'll get a proper wiki section started. Furthermore, one thing I am hoping this program will help bring is not only a stronger interest in the core and a fresh injection of talent but more importantly I hope we'll be able to contributors from our various communities that are scattered across the internet that barely ever interact with the internals. Hoping this email reaches as many of you and that my message is properly conveyed :-) P.S. This is really an attempt to find volunteers. If you are interested please feel free to contact me directly if you prefer so we can start organising whatever would have to be done: dav...@php.net References: [1]: http://pythonmentors.com/ [2]: http://jessenoller.com/2011/03/25/just-proposed-python-core-mentorship-program/ -- David Coallier Orchestra.io -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] RFC: Short syntax for Arrays (redux)
Even though I have quite mixed feelings about this, I think I am
finally ready to cast
my +1. Over the past few days I've discussed with a few people and
noticed the need, or rather a strong desire to have this feature in
PHP and most people seemed to care only little about how it was done
as long as it was done.
For the record, my initial objection with the array literals was never
the array literals themselves but the lack of object literals to
accompany the patch. I still strongly believe that we need both arrays
[] and objects {} for a complete consistent implementation,
however I'm willing to make a compromise and move forward rather than stalling.
Consider this my official +1 for [key = value]
--
David Coallier
--
David Coallier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Implicit isset/isempty check on short-ternary operator
Hey there,
I've been working on a little patch that will allow variables ($1) in
a short-ternary operation to go through an implicit isset
(zend_do_isset_or_isempty) check so that the average use-case for the
short-ternary operator doesn't yield in a notice whenever the first
variable of the expression isn't set.
So the use-case I'm considering is the following:
?php
$list = array('name' = 'list');
echo $list['name'] ?: 'List not set.' . PHP_EOL;
echo $list['name-notset'] ?: 'List not set.' . PHP_EOL;
?
This example, which we all know, will result in a notice for the
second echo statement because the requested array-key doesn't actually
exist in the array.
Now, looking at the original implementation thread of ifsetor and ?: I
can see that Marcus' patch had an implicit isset() on the first
variable but I cannot seem to track down why this wasn't implemented
in the final patch.
I'm merely looking for counter-arguments as to why an implicit
isset/isempty should not be performed when the first argument is
indeed a variable and not an expr. The only counter-argument (If this
can even be considered remotely related to an argument) is that having
an implicit isset() would return the boolean value of the check. See
in the common misconceptions of ifsetor on the wiki [1]
I am not trying to revive ifsetor() because I believe this is an
amazingly ugly language construct and I don't think it has an actual
place in PHP however, implicitly performing the ifestor check on
variables and not expr could greatly improve it's usability I
believe.
Anyone has notes about the arguments against the implicit check at the
Chicago Round-Table meeting?
Thanks,
[1] Ifsetor cached wiki rfc:
http://webcache.googleusercontent.com/search?q=cache:jKrV2u7jeokJ:wiki.php.net/rfc/ifsetor+php+ifsetor+patchcd=1hl=enct=clnkgl=usclient=firefox-asource=www.google.com
--
David Coallier
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SVN Account Request: jespino (Try 2)
I'll take care of your account. I just have to review and make sure you are legit ;-) hehe, seriously though, I'll check it out and approve your account. 2010/6/11 Hannes Magnusson hannes.magnus...@gmail.com: 2010/6/11 Jesús Espino jespi...@gmail.com: Then?? I have to fill again the form?? simply wait for any in the pear-group add my account to the svn repository?? open a new thread in pear-group mailing list?? Wait for couple days. If you haven't recieved any mail by then, then mail pear-group@, poke whoever told you to submit the form, or poke around on #pear (EFnet). Stuff takes time, especially during conference season :) Be sure to read read the mailinglist rules too: http://no.php.net/reST/php-src/README.MAILINGLIST_RULES -Hannes -- David Coallier -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [PHP] PHP 6 and MySQL 5 for Dynamic Web Sites Book
Does no one see the inherent issues in buying a book about a not-feature-complete version of the language? I suspect in 2007/8 Larry thought that PHP6 was actually going to be released some time soon, rather than inventing a new roadblock with PHP5.3 - which is what the book now needs re-writing to support? This doesn't belong on internals. Please use php-general or if this is where it was originally posted, keep it there. Thanks, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Supporting ArrayObject in array_* functions
What do you think about the possibility to support ArrayObject instances in array_* functions? If you all agreed on this, I can definately help to complete the patch, but I need some initial guidance to finish at least the first function. I think it's a marvelous idea :) I'm attaching Travis Swicegood to this as he had cooked a very simple but effective patch for that at #tek09 -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Type hinting/casting request for vote
+1 -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Type hinting revisited for PHP 5.3
2009/7/1 Ilia Alshanetsky i...@prohost.org:
There has been quite a bit of discussion on this list, IRC, developer
meetings, etc... about introduction of type hinting to PHP. Most people
appear to think that this would be a good idea, but there is a reason why it
is not in PHP already. The main source of conflict appears to be that in
some cases typical type hinting is just too strict for PHP's typeless nature
(most people expect that 1 == 1, while int type hint would definitely
reject string 1). Personally, I disagree with that opinion, but I can
understand people who raise that issue. At work we've been using PHP 5.2
with type hinting for nearly 2 years now with great success, it makes code
much easier to read and understand and the security benefit of type hinting
is not to be under valued. In many cases type hinting can present a last
line of defense against unexpected input for numeric fields, which are
typically abused to do SQL injection.
I've taken a few hours this morning to port my 5.2 type hinting patch to
5.3. In recognition of a need for a more 'flexible' numeric type I've
introduced (numeric) type hint that would allow bool/int/float data types as
well as a string containing a numeric entity as identified by
is_numeric_string(). For completion i've also added (scalar) data type that
will allow any scalar data element.
The patch is available here: http://ia.gd/patch/type_hint_53.txt
It should be noted that this patch is fully compatible with opcode caches
and and requires no changes on the part of an opcode cache such as APC to
work.
My hope is that the latest changes will allow this to become a standard part
of PHP.
Brilliant stuff Ilia!
One thing I noticed in the patch is:
+ST_IN_SCRIPTING(string|binary|unicode) {
+ return T_STRING_HINT;
+}
which makes sense if we keep for PHP6 but doesn't for 5_3 which afaik
doesn't have (unicode) casting yet :) I think that's nitpicking I
agree and I just want to make sure that this doesn't become a
documentation issue for people who'd think you can hint using unicode
or even see article saying you can hint with unicode.
Makes sense for PHP6 though but since you merged your patch from 5.2 I
figured I could ask :)
Apart from that this is awesome and am I glad that we are not trying
to cast automatically!
+1
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Removing zend_hash_func in PHP 6.0
2009/5/26 David Soria Parra dso...@gmx.net: Hi List, I recently discovered that zend_hash_func is equal to zend_get_hash_value. To clean this up, I would like to remove zend_hash_func in favor of zend_get_hash in HEAD. If there are no objections I would commit a patch in a few days. Did you grep through pecl and the source to make sure it won't break anything? If you did, then I see no problems. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] How to contribute for PHP Internals
2009/5/14 Sahid Ferdjaoui sahid.ferdja...@gmail.com: Hello Internals, I want to contribute for PHP Internal, but i don't know how to do it. I am ready to give approximately 6 to 12 hours per week for PHP. i have checked a wiki, but i don't see a get involved section and i do not know how to start :) The best way to get started is to check http://php.net/anoncvs make a checkout of HEAD (php6) and then go to http://bugs.php.net start making patches and attach them to bug reports. From there you will gain developers trust (People will be tired of committing all your patches) and at some point you'll be granted with an account :) Good luck and welcome :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Update to Zend Highlighter
2009/4/2 Kalle Sommer Nielsen ka...@php.net: 2009/4/2 Kalle Sommer Nielsen ka...@php.net: Hi Justin Attached a patch instead, hopefully this will work ;) I really do like this idea :) Let's just commit it. I would however like ot see the naming stucture Justin used in the first example by prefixing the CSS classnames by php. This will greatly help the inclusion into other considering that comment and default are widely used (not sure about the other ones) for general purposes usage (see google codesearch for example). Cool work, do we go by adding 6 new ini settings and making sure they are prefixed by default? Also I guess we'll have to attach a css file with that? Inline css at the top of the generated highlighted block maybe? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC - XDebug profiling web front-end
2009/3/31 Alpár Török torokal...@gmail.com: Hi, I am interested in this project and would like to join GSoC. I have red trough the google FAQ and completed a sing-up form, however i am not sure where to go or what to do from here. Any guidance is appreciated. I'm sorry to tell you that but xdebug web profiling was a project for last year. Please read http://wiki.php.net/gsoc/2009 for this years GSoC ideas. Cheers :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Focus on HEAD
2009/3/27 Hannes Magnusson hannes.magnus...@gmail.com: 2009/3/27 Felipe Pena felipe...@gmail.com: Hello, just to inform, I've commited (yesterday) the patch removing the UG(unicode) checks, etc across all source (except mysql exts). As the patch has 492K, looks as no mail will be sent. [...] Would you mind letting the list know when the commit has gone through? That way we can catch any possible bugs quicker? (I know we could simply do cvs up -dP repeatedly until we see changes but y'know ;-)) Thanks a million D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Focus on HEAD
2009/3/27 Sebastian Bergmann s...@sebastian-bergmann.de: Felipe Pena schrieb: + - Removed: + - UG(unicode) checks + - pcre_cache_entry.unicode_mode + - Changed: + - ZEND_STR_TYPE - IS_UNICODE + - convert_to_text - convert_to_unicode + - convert_to_text_ex - convert_to_unicode_ex + + (Felipe, Steph) Yay you! Only thing I have to say about this is: Dar dar sorry about this :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 TODO list
2009/3/13 Andrei Zmievski and...@gravitonic.com: Hannes Magnusson wrote: Regarding the migration item... Wasn't there a gsoc project last year that did exactly that? I think there was, but I don't know if they actually did anything. Actually there was one which I was proposing to mentor since you weren't there Andrei, but it basically got no attention whatsoever and not proposal from the students, thus no project :) Hope this helps a bit. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 6 TODO list
Scott did. I have asked _multiple_ times about the status of the project, all I got was he passed. Quote from Scott (from few months ago): he was to implement unicode support in more modules and convert an application. He's in the process of writing a conversion guide and I believe he did openssl, imap and updated date. I am still looking forward to see the results, even though its almost a year behind schedule. Ah yeah I remember now. Well, in a way, good to know the student has passed. Did we get more % one the completion? I'd say that 69% is merely a change from the last 2 years. Anyways, issues with students and progress should be somewhat resolved this year with the new approach to student mentoring and student reporting tasks I'd say. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] phar update
When I say working, I mean 100% of non-skipped tests passing, no compile warnings. The tests exert 80% code coverage, mostly leaving untestable stuff like errors that are only likely to occur when the disk crashes. Seriously well done! Kudos -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC 2009
Of course being mentor for the past 2 years I want to be a mentor again this year. But there are a few things we need to fix. I sent an email to the other mentors about 3 months ago about things that went not-so-well last year. Here are a few things that were suggested and came out of this discussion that we should do in order to improve this year's GSoC. 1. Students to send weekly or bi-weekly emails to public lists to inform of progress and ask for help if needed (After all it's open source not only the mentor can help :P) - we should make sure we strictly follow this rule as last year it was somewhat forgotton. 2. Having a blog where each student has to post about (This could maybe be used instead of the weekly mailing list email?) 3. A public repository for all the projects within PHP GSoC. Easily findable and browsable. 4. If a private list incurs then a CC to the public development mailing should be done. 5. 2 mentors per project (this was mentioned above) EOF; Basically what has to be remembered from last year is that even though some projects did very well and our organizational activities got better than the year before, we still lacked communication within the PHP GSoC projects in general. For instance I left on honeymoon for a tad longer than expected and no one knew what was happening with my student, it was hosted on another CVS server and only one person from that other server was available but without me telling the admins of the project, it was quite complex for them to retrieve and get CVS access to which repository. Luckily enough Derick was the admin of the other CVS repo so he got us fixed but the problem still remained that with the lack of communication, my student, the admins and me were all in the dark about the student's progress. After the midterms started a weekly email, with a lot more communication and the project developed a whole lot faster, the student obviously gained confidence and commited a whole lot more to the project. I'm know some other mentors have some other stories they could share but what I'm trying to outline here is that communication is the key, and the more people ready and able to help can make the project go much faster, make the student feel much more in control and make a solid final product. Should we start a regulations and procedures to follow page on the wiki and simply go from there? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Reserved namespaces
Forgive me if I've missed this in the heat of all the namespaces discussions. Did we consider having reserved namespaces, like 'PHP' or 'SPL', so that if a user tries to declare a namespace with that name an error is raised? I'd say what you are looking for is probably this. http://wiki.php.net/rfc/namespaces-for-internal-classes I know this has been discussed but I'm not sure if any decision has been made on that subject. Or if anyone had time to start digging into this issue further than discussions. Lars? Cheers, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Private member/method access inconsistency
To me it looks like a large inconsistency in the way we invoke overloaded handlers for members vs. methods. I am not sure how it came to be this way, but it's probably something we should fix. We can either remove the call to __get() on private member access, or add call to __call() on private method invocation. The former approach presents more of a BC problem IMHO, so I am advocating the latter. I've attached a simple patch for consideration. I'd say go ahead, this sounds like common sense to be consistent in both methods and members. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Proposal: array_flatten function
cvs diff -u against 5.3 branch shoould be ok for the start. after positive review, cvs diff -u against HEAD would be needed to I really have to say it, you should make your changes to HEAD __first__ then to 5.3. Not the other way around :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] documentation
can you guys give me an advice about where find good documentation/books about php C module development? For starters you can look at this: http://short.ie/extendingphp This is linking to Sara's blog. Oh look on the right hand side... you can buy it from there as well :D Great book really. Good luck, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplHeap-key()
I noticed that SplHeap returns the current element count of the heap from key(). I think it should return count - 1 to reflect 0 indexing. key won't be called outside of an iterator, so this makes sense. I'd say this is a bug as well, would you mind opening a bug and assigning it to me please? Etienne/Marcus, do you mind if I go ahead? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] quick polls for 5.3
1) ext/mhash in 5.3. ext/hash has all the functions, so the entire BC break
will be that if (extension_loaded('mhash')) will need fixing if mhash is
removed (answer both)
I) enable ext/hash by default
+1
II) remove ext/mhash
+1
2) deprecate ereg*. ext/ereg is an extension as of PHP 5.3. Since ext/ereg
is more or less redundant with ext/preg and is likely to not get much
unicode love for PHP 6, the question is if we should mark it with a
E_DEPRECATED in PHP 5.3
+1
3) resource constants (choose one)
c) Document as is
+1
4) keep ext/phar enabled by default in 5.3?
+1
5) keep ext/sqlite3 enabled by default in 5.3?
+1
6) enable mysqlnd by default in 5.3? (answer both)
I) enable mysqlnd by default
I'd say personally +1 because I have it enabled everywhere already but
thinking in a larger user base where not everyone is using mysql I
have to say -1
II) also enable ext/mysql, mysqli und pdo_mysql by default since there will
be no external dependencies in this case
+1 if it ends up turned on by default, -1 otherwise.
7) should Output buffering rewrite MFH? this one comes with some baggage, we
need enough people to actually have a look at how things are in HEAD and
make it clear that they will be available for bug fixing and BC issues
resolving. the risk here is obviously that any BC issues will be hard to
isolate for end users.
-1
8) MFH mcrypt cleanups in HEAD. either the make sense or they dont, so
either (choose one)
b) MFH to 5.3
+1
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace Resolution
2008/11/4 Andrey Hristov [EMAIL PROTECTED] Ryan Panning wrote: use 'NsA\NsB\NsC\func_c()'; OMG That looks UGLY1 This is exactly the kind of comment that is both useless and pointless. Could you please make sure that you have a valid point with a subject, arguments, examples or at least ideas and a direction next time you post. Thanks, -- Slan, David
Re: [PHP-DEV] mSQL - goto pecl;
What about moving mSQL to pecl? :) +1 -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Namespace issues
shift+;(x3) vs \ Ok I'll try to make a very neutral comment. For the moment most are still using an english keyboard (no matter which english in this case and I'd actually be interested in knowing numbers for a fact if anyone's got something) and ergonomically speaking, ::: is much easier to type than \ for those who actually learned to type with the adsf jkl; keyboard. When you learn typing you usually learn to type using the left-hand side shift key for most of the letters/words, for instance typing : doesn't require a movement of the right hand since your pinky is already on the ; key whereas the \ key requires a not-so-used movement of the hand. Anyways, I was just saying that without considering the question because I absolutely don't feel like redicussing this over and over. We have had a massive list fight over 3-4 years ago about it and I'm not getting into this one. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] json_encode ignores protected/private class members
Ok, nice solution, but I still don't see why json_encode ignores
protected/private class members. I mean, why we need this feature.
Because, in theory, it shouldn't even be able to see those members?
Stefan's right. Unless you are in the local scope or inheriting the
object you shouldn't be able to see those variables. And I have yet to
see
classs Name extends json_decode($jsonValues) { }
That's the point in having access modifiers. Unless I'm mistaking
there's no bug there.
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] php7- dropping the $ from the variable name - rfc
sure we can break things if there is a compelling reason to do so, i'm just totally missing the compelling part here ... This is not going to happen. This thread is over. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Subversion migration
By that I meant that several scripts which come with subversion are written in Python. They're pretty easy to replace with PHP scripts though if we do decide to use eg. the pecl svn extension. We would need to modify them extensively anyway if we were to use a system analogous to the one in use in CVS now (avail system comes to mind), so rewriting them in PHP would probably take the same amount of time/effort. I personally wouldn't mind using PHP at all (would even prefer it as I wrote in my original mail to svn-migration). Could we please move this discussion to the svn.migration list please? Thanks, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] allow T_INLINE_HTML before T_NAMESPACE
2008/9/12 Greg Beaver [EMAIL PROTECTED]: Hi, This is a simple patch that allows files like this: main.php: html head titletemplate example/title /head /html body ?php namespace my::template; // stuff ? /body Is it me or this doesn't look really clean? I have a clear idea that namespaces are there to add an extra structural layer to the code and not to be randomly used in some HTML/PHP/Javascript mixing. Since the current namespace implementation doesn't want to have multiple namespaces per file, I think we should restrict a namespace per file to... a namespace per file, and nothing else. I can't imagine taking over someone's code who had declared a namespace under is footer template. Perhaps I am missing something but that would be bloody ugly in the end :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: 5.3 Backwards Compatibility
2008/9/10 Lester Caine [EMAIL PROTECTED]: Lukas Kahwe Smith wrote: Hi, So let me get this straight, you are complaining that all the new features and changes in the 5.3.0 alpha releases are not perfectly documented yet? PLEASE re-read the original post. If my comments and QUESTIONS are taken as complaints then OK. That is not what was intended. searching on 'namespace' was not giving me anything - I did not think to try 'namespaces' - goto has not got any notes yet? - I've not even looked at phar as it's not on the list I gave the link for so I assume it's still an optional PECL package ... The 'complaint' that I have is that the changes being introduced DO seem to be bringing in problems which when corrected for 5.3 then cause other problems for previous versions of PHP. As an example, the bitweaver framework currently runs out of the box on PHP4 and PHP5. RUNNING it on PHP5.3 gives various warnings and errors that handling for 5.3 then messes up previous versions although WHEN migration is documented there may be options provided that solve those problems? ( And PEAR comes into this equation since potentially we may have to take care of pre and post 5.3 situations? ) Hanging fixes through the code with 'version selects' has not been necessary much up to now but 5.3 seems to be heading that way? We are currently working through the bitweaver 2.1 testing, on 5.2.6 and below so have not yet had time to do any more than checking the code runs on 5.3. The list of things to be looked at on 5.3 was growing so has had to be shelved until the next bitweaver release is out. One has to allocate time productively and BW is currently paying the mortgage for me! Lester, if you have more complaints or suggestions regarding PEAR, I would like to ask you to go on pear-dev. We'll be happy to help you resolve the situations or work something out. Many developers there are running 5.3 as testers and we have had all the problems. Thank you very much, -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Ob_start, protected obHandler method, nod detecting $this-geMe () kind of error!
2008/9/4 Catalin Zamfir Alexandru | KIT Software CAZ [EMAIL PROTECTED]: Actually it's not when you want to separate Output Buffering from ErrorHandling. :) . and YES, you can access obHandler when it is protected, because you extends the abstract base class, but it fails miserably on the $this-getMe () error type. Just a side note for this ... thread: http://ie.php.net/reST/php-src/README.MAILINGLIST_RULES Thanks :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
2008/9/2 Scott MacVicar [EMAIL PROTECTED]: Hi All, Attached and uploaded [1] is a patch to add the OpenSSL random pseudo byte function, at the moment it will return FALSE if the bytes aren't considered cryptographically strong, I am however considering making this parameter controlled. Any objections to me applying this to 5.3? I'd say that 5.3 should be a rather stable version and that if we add features we should make sure they are rock solid now. Perhaps adding the control (Parameter to control the security/cryptography level) now would save time and would make it a thing less to look back in the future. What do you think? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] OpenSSL random pseudo bytes
This function has been in OpenSSL for 8 years and supported by every version since 0.9.5. It's literally just exposing the API, it's safe for inclusion in 5.3 in my opinion. I didn't express myself very clearly. What I meant is that we should probably add that switch for the return right now instead of later (IE: I am however considering making this parameter controlled.) I think it's safe to include it but I'll await on the RMs before saying anything :) Exposing OpenSSL's API is a good idea imo. -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Alias stream_context_get_default() as stream_context_set_default()
I had suggested a second optional argument that could be assigned the resource (context), and then return true. Though I still think that returning the resource is the best option. Runs and compiles fine from here. I like the idea too. Great first attempt :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GSoC Update (XDebug project)
This sounds cool. Can we try it somewhere? I'll setup a host in a few days when I get back from vacation :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/28 Jordan Wambaugh [EMAIL PROTECTED]:
On Jun 19, 2008, at 7:06 PM, Stanislav Malyshev wrote:
I have cleaned up Zend engine functions, converting them to the new API,
but there are about 1000 instances throughout PHP code (especially
ext/standard) which still use the old way. This way is less correct,
inconsistent with the new code, gives worse error messages, more prone to
various bugs, etc. All new extensions and functions use the new way, and the
only reason for keeping the old way in the code seems to be that nobody
cleaned it up. Somebody has to bring the old ones into sync, and I don't
think I personally will have time to do it in near timeframe. So if anybody
could step up to that - by doing at least part of the work - that'd be
great. The work is pretty simple, taking something like:
I went ahead and took care of standard/assert.c and
standard/formatted_print.c for 5.3 as well. All tests are passing.
Cheers!
--
Jordan CM Wambaugh
[EMAIL PROTECTED]
Index: assert.c
===
RCS file: /repository/php-src/ext/standard/assert.c,v
retrieving revision 1.60.2.3.2.6.2.2
diff -u -r1.60.2.3.2.6.2.2 assert.c
--- assert.c31 Dec 2007 07:17:14 - 1.60.2.3.2.6.2.2
+++ assert.c28 Jun 2008 03:39:28 -
@@ -139,7 +139,7 @@
Checks if assertion is false */
PHP_FUNCTION(assert)
{
- zval **assertion;
+ zval *assertion;
int val;
char *myeval = NULL;
char *compiled_string_description;
@@ -148,15 +148,15 @@
RETURN_TRUE;
}
- if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, assertion) ==
FAILURE) {
+ if (ZEND_NUM_ARGS() != 1 || zend_parse_parameters(1 TSRMLS_CC, z,
assertion) == FAILURE) {
WRONG_PARAM_COUNT;
}
- if (Z_TYPE_PP(assertion) == IS_STRING) {
+ if (Z_TYPE_PP(assertion) == IS_STRING) {
zval retval;
int old_error_reporting = 0; /* shut up gcc! */
- myeval = Z_STRVAL_PP(assertion);
+ myeval = Z_STRVAL_PP(assertion);
if (ASSERTG(quiet_eval)) {
old_error_reporting = EG(error_reporting);
@@ -181,8 +181,8 @@
convert_to_boolean(retval);
val = Z_LVAL(retval);
} else {
- convert_to_boolean_ex(assertion);
- val = Z_LVAL_PP(assertion);
+ convert_to_boolean_ex(assertion);
+ val = Z_LVAL_PP(assertion);
}
if (val) {
@@ -235,26 +235,25 @@
}
/* }}} */
-/* {{{ proto mixed assert_options(int what [, mixed value])
+/* {{{ proto mixed assert_options(int what[, mixed value])
Set/get the various assert flags */
PHP_FUNCTION(assert_options)
{
- zval **what, **value;
- int oldint;
+ zval *value=0;
+ int oldint, what;
int ac = ZEND_NUM_ARGS();
- if (ac 1 || ac 2 || zend_get_parameters_ex(ac, what, value) ==
FAILURE) {
+ if (ac 1 || ac 2 || zend_parse_parameters(ac TSRMLS_CC, i|z,
what, value) == FAILURE) {
WRONG_PARAM_COUNT;
}
- convert_to_long_ex(what);
- switch (Z_LVAL_PP(what)) {
+ switch (what) {
case ASSERT_ACTIVE:
oldint = ASSERTG(active);
if (ac == 2) {
- convert_to_long_ex(value);
- ASSERTG(active) = Z_LVAL_PP(value);
+ convert_to_long_ex(value);
+ ASSERTG(active) = Z_LVAL_PP(value);
}
RETURN_LONG(oldint);
break;
@@ -262,8 +261,8 @@
case ASSERT_BAIL:
oldint = ASSERTG(bail);
if (ac == 2) {
- convert_to_long_ex(value);
- ASSERTG(bail) = Z_LVAL_PP(value);
+ convert_to_long_ex(value);
+ ASSERTG(bail) = Z_LVAL_PP(value);
}
RETURN_LONG(oldint);
break;
@@ -271,8 +270,8 @@
case ASSERT_QUIET_EVAL:
oldint = ASSERTG(quiet_eval);
if (ac == 2) {
- convert_to_long_ex(value);
- ASSERTG(quiet_eval) = Z_LVAL_PP(value);
+ convert_to_long_ex(value);
+ ASSERTG(quiet_eval) = Z_LVAL_PP(value);
}
RETURN_LONG(oldint);
break;
@@ -280,8 +279,8 @@
case ASSERT_WARNING:
oldint = ASSERTG(warning);
if (ac == 2) {
- convert_to_long_ex(value);
- ASSERTG(warning) = Z_LVAL_PP(value);
+ convert_to_long_ex(value);
+ ASSERTG(warning) = Z_LVAL_PP(value);
}
RETURN_LONG(oldint);
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/28 Jordan Wambaugh [EMAIL PROTECTED]:
On Jun 28, 2008, at 7:27 AM, David Coallier wrote:
The idea of the new parsing parameter is to catch the number of
parameters as well. For instance when you have
if (ZEND_NUM_ARGS() 2) {
WRONG_PARAM_COUNT;
}
then your zend parse param function call should have 2 params or more
Ex:
int argc;
char *name;
zval **other;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, sZ, name,
other, argc) == FAILURE) {
return;
}
This way of parsing the parameters remove the ZEND_NUM_ARGS() and
WRONG_PARAM_COUNT and adds consistency in the return error messages
across the language.
Also next time please read the previous entries of the thread :
See: http://url.ie/hck that was about the 3rd or 4th message.
Anyways that's ok, I lot of conflicts now in formatted_print.c and
assert.c but I'll work around them to get the resolved. We just have
to get organized on which files we'll be working on then. Right now,
Olivier is working on file.c and has done string.c so please don't do
those 2 files.
Ok, sorry, I didn't catch the thread where you said you were going to work
on standard. Do you want me to fix it so I'm not checking ZEND_NUM_ARGS, or
should I just leave that to you?
Go ahead, you are pretty well started, I'll adjust after you are done :)
--
Slan,
David
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
The attached patch may also help both core and PECL extensions, emiting a deprecation compile warning when those functions are used. A bit late to answer but very good idea :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/22 Lukas Kahwe Smith [EMAIL PROTECTED]: On 20.06.2008, at 01:06, Stanislav Malyshev wrote: While we nearing the release of 5.3 (hopefully?), there are many functions in the PHP code which still use old parameter parsing API (zend_get_parameters_ex) instead of the new one (zend_parse_parameters). is this in any way related to the parameter parsing API change that caused the BC break in array_merge() back in PHP 5.0? If so then I would appreciate extra care to be taken to minimize these kinds of BC breaks and at least make sure that these breaks are well documented. Ok, with the tests being ran we are minimizing the chances of bc break but I agree and extra care should be applied. We'll make sure this care is applied. regards, Lukas Kahwe Smith [EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
Ok, with the tests being ran we are minimizing the chances of bc break but I agree and extra care should be applied. We'll make sure this care is applied. And sorry about the email before, I forgot to remove the junk. :) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/21 Alexey Zakhlestin [EMAIL PROTECTED]: I did curl for 5.3 Grand! did you commit it already? -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/21 Rasmus Lerdorf [EMAIL PROTECTED]: Alexey Zakhlestin wrote: On 6/22/08, David Coallier [EMAIL PROTECTED] wrote: 2008/6/21 Alexey Zakhlestin [EMAIL PROTECTED]: I did curl for 5.3 I don't have karma. You do now. Cheers Mr. L -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] cleaning up the functions - any volunteers?
I'll take a few
2008/6/20 Stanislav Malyshev [EMAIL PROTECTED]:
Hi!
While we nearing the release of 5.3 (hopefully?), there are many functions
in the PHP code which still use old parameter parsing API
(zend_get_parameters_ex) instead of the new one (zend_parse_parameters).
I have cleaned up Zend engine functions, converting them to the new API,
but there are about 1000 instances throughout PHP code (especially
ext/standard) which still use the old way. This way is less correct,
inconsistent with the new code, gives worse error messages, more prone to
various bugs, etc. All new extensions and functions use the new way, and the
only reason for keeping the old way in the code seems to be that nobody
cleaned it up. Somebody has to bring the old ones into sync, and I don't
think I personally will have time to do it in near timeframe. So if anybody
could step up to that - by doing at least part of the work - that'd be
great. The work is pretty simple, taking something like:
zval **data;
if (ZEND_NUM_ARGS() != 1 || zend_get_parameters_ex(1, data) == FAILURE) {
WRONG_PARAM_COUNT;
}
convert_to_string_ex(data);
and move it into:
char *str;
int str_len;
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC, s, str, str_len)
== FAILURE) {
return;
}
and of course convert use of data zval into use of str.
This needs to be done carefully as not to break things on some more tricky
functions which may get arguments of multiple types, etc. Also, some tests
which check error messages may need to be fixed since new API gives more
detailed messages.
zend_parse_parameters documented here:
http://www.php.net/manual/en/internals2.ze1.zendapi.php
though some of the newer parameters aren't (C, h, f, Z) so one may need to
look at the code at zend_API.c.
P.S. if some genius would invent a script to automate that - it'd be
awesome, but I don't have very high hopes on that. :)
--
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
--
Slan,
David
Re: [PHP-DEV] cleaning up the functions - any volunteers?
2008/6/20 Olivier Hill [EMAIL PROTECTED]: Want some help D? :) Olivier On Fri, Jun 20, 2008 at 11:18 AM, David Coallier [EMAIL PROTECTED] wrote: I'll take a few Yep, after speaking with felipe, we (you and I) have standard/ -- Slan, David
Re: [PHP-DEV] magic quotes finale
cu, Lars P.S.: Silence agrees doesn't work, silence is void. Well, if silence is void: TAKE IT OFF!!! (+1 ... once again on this subject) -- Slan, David -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl documentation
On 11/04/2008, Alexey Zakhlestin [EMAIL PROTECTED] wrote: I noticed, that http://www.php.net/~helly/php/ext/spl/ was updated almost a year ago. Is the newer version available anywhere? Good point, there're so many new things in there. Marcus? Etienne? Anyone up to do regenerate some docs ? Thanks, D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl documentation
I think all effort should go into writing real documentation within the phpdoc cvs module instead of unreadable and unofficial doxygen output. Personally I feel the link to the doxygen output should be removed from php.net/spl (but won't) so anyway those are my feelings. Etienne is planning to work on both, which is great, but I encourage everyone to update the official spl documentation and not worry much about doxygen. I agree with you on the part that efforts should be put for the phpdoc but I personally consider doxygen's output to be much more complete than any phpdoc output. The doxygen output is very technical and usually if you are looking for something very specific, you'll find it. PHPDocs and Doxygen outputs are really 2 separate beasts, for instance with Doxygen you'll see a clear hierarchy between the objects/classes and which classes they inherit and implement whereas the phpdoc will describe the functions clearly. There are many things that doxygen does that phpdoc doesn't do and the same for phpdoc and doxygen. Anyways, I think we still need that doxygen output and it would be plain bad to scrap it. D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl documentation
I think having core module that is documented by doxygen is a shame. And if there's anybody working on docs, the work should be done first on official docs in the manual, which right now are in the virtually non-existent state. Doxygen is a nice thing but no replacement for real documentation. Jesus christ! What's the amplitude this is taking ? We are not talking about keeping SPL ONLY documented in Doxygen, it's simply a nice addition to have it __DOT__. The only thing that Alexey asked was if there was some regenerated docs. Please, if you feel like you still have problems with SPL in the core or any other problems with documentation of extensions because of it's documentation, just start another thread. This one should be long over, the point was just to ask Marcus to put a new generated version online not to start a war on SPL's doxygen's documentation. Thanks, D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_5_3 GOTO?
I see there was a patch added to CVS 2 days ago which added the T_GOTO token. This has since broken the Zend Framework for me as they're using the goto keyword on some of their objects. I thought it was version PHP 6 that was adding the goto operator. Been discussed on this list that certain HEAD (php6) features should be backported to 5_3 Does anyone know the state of things for the goto keyword and PHP 5.3? See http://marc.info/?l=php-internalsw=2r=1s=Backporting+to+5_3q=b That should answer your questions :) D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Opensource / Job
I have been a developer for about 11 years and been using PHP about five Today i am looking for a job that can be done in my own environment and i thought that contributing to opensource projects could be a good possibility, if there is that possibility of course, because i am not sure if this is being done and what are the requirements to be able to apply for this The reason why i am posting here, in a PHP mailing list (internals list), is that i do believe about this language, its future, and i really enjoy programming in it because it remains simple, very similar to C and flexible If any of you could tell me how can i try to contact somebody for this kind of job i will really appreciate your help, since i do not know nobody working in this situation This list has for purpose php development (It's internals as the name states). Please do not post such comments here, you can try on php.dev but this is not a personal job posting area place. One thing I'd suggest is to look at our Google Summer of Code ideas page (http://wiki.php.net/gsoc/2008) and maybe get a project there. I'll repeat to make sure it's understood: This list is not a self promoting page (even though sometimes it looks like it) Thanks a lot for understanding :) D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [RFC] Namespace syntax decision
Why can't we stick to consistency ? PHP (classes, functions, interfaces, abstracts, etc) are all done the same way. What is the need of changing this ? I see reasons like : - I don't like indentatation (Answer to that: PHP must make you quite sad then... and I can't imagine what python makes you feel like...) So I think what we should do here is either reassemble the ideas (That were of course lost since the initial discussions). - Why did we want to call it a package ? Simply because it behaves exactly like packages ? - Why do we decide to have a whole new way of declaring namespaces ? (IE: No braces) - Since we decided to have namespaces what is so bad about having nested namespaces? Do we want to be that different from others? I think having a solution that looks a lot like other software languages is something that will not only bring us users but also bring us a lot of love from other language developers (when they have to use PHP (because yes, some have to use other languages)). Greg came up with a pretty good patch for multiple namespaces per file. However it does not follow the PHP Coding Practices - In terms of style and characters used. Greg? Stas? Dmitry? Could we get a resume of the backstage talks you guys spoke about? I'm sure you did so just a little taste to inform us all of why we decided to change PHP's general syntax would be awesome :) Thanks, D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHPUnit under the umbrella of PHP for GSoC
I think the real question we have to ask is Do we consider PHPUnit standard for PHP Development Unit Testing ? If so, PHPUnit gets a grant (or a chance to get one under the PHP Project umbrella) If not, then it doesn't. I consider PHPUnit the standard for Unit Testing in PHP, now what do you all think ? -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: How PHP utilizes the Google SoC
Good to know about the Wiki, too, Phillip. I actually saw an email come in this morning with the wiki.php.net domain as the subject. Maybe I'd been missing a lot of the discussion somehow, I didn't know that it was still moving forward. Lukas has been very quick and responsive on this, not much discussions as it seems to be the biggest stopper on that list :) Good work Lukas, very good work. -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Deprecating php_dirname() in 5_3, removing in HEAD
I'm talking about extension developers. We will all have to add yet another #ifdef for this function, in the implementation or to define php_dirname to keep the implementation clean(er). As it is good to clean up codes, I'm not sure to remove this function is a good thing. That's why I suggest removing it in 6, and deprecating it from now on. As 6 will break everything anyway. I go it but there is no easy to deprecate an internal function. Except to spare two #define php_(u)_dirname in HEAD, I still see no gain :) Perhaps it's time to make a compatibility extension with all those ifdefs everywhere and engine hooks. -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: RFC: How PHP utilizes the Google SoC
Philip Olson wrote: The SoC Administrator is designated - hopefully before February 1. Marcus was last year, he is again this year. Somewhat behind the ball, are we? :o) Nothing is behind the walls... for once :) -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should
really be
something that only marks a method as private if at all. That can be
done as:
'foo as private' since private is a keyword it cannot conflice
anyway.
I like this solution.
Yes to me it seems like we can solve the entire lack of
encapsulation through aliasing/hiding by making the following changes
to the original proposal:
A trait may contain methods and properties. When importing a trait
into a class, all methods and properties are imported in a way that
makes them only visible within the trait (I dont like the use of
private here .. its what confused me in the first proposals of this
approach by Marcus/Andi). The user of the trait can however explicitly
make properties and methods from the trait visible to the class
importing the trait. Also the trait using class can explicitly say
that it wants to override a method/property in the scope of the trait.
This way:
1) there is little chance of accidentally breaking a trait
2) changes within the trait should not break anything in the trait
using class, unless the developer explicitly messed with the traits
internals in the class using the trait. in that case however he can
quickly spot the potentially problematic lines
I have been uncomfortable with the current trait suggestions because
they occur in the body of the class, whereas extends/implements is
outside. I think there is a way to handle this, however.
I dont agree here. traits are different. They do not affect what the
class is. They change what it can do and as such the stuff should be
defined next to properties and methods.
?php
trait trait1 { function a(){}}
trait trait2 { function a(){}}
class Blah extends ... implements ... traits trait1, trait2, trait3 {
}
?
Here it gets worse. Now if I refactor things into a trait, I have to
start changing all uses of those methods.
@Greg: I think you are going in the wrong direction here.
Fun that you mentionned that structure greg because I was thinking of
something along those lines. Something very similar actually but the
aliasing could look like this:
trait One {
function name() { return __TRAIT__; }
function removeMe() {}
}
trait Two {
function name() { return __TRAIT__; }
}
class Reel traits One, Two
{
override One::name with Two::name;
remove Two::removeMe;
}
$object = new Reel();
echo $object-name(); // Echos Two of course.
I find that rather clean and clear that you we are either overriding
what with what and then removing a method. But as lukas mentionned, we
may be stepping out of line here...
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David,
Re-read what you are replying.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Traits for PHP
On Fri, Feb 22, 2008 at 10:32 AM, David Coallier [EMAIL PROTECTED] wrote:
On Fri, Feb 22, 2008 at 10:03 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote:
On 22.02.2008, at 15:45, Gregory Beaver wrote:
Marcus Boerger wrote:
Hello Lukas,
alright,
'foo as bar' is ok to me and does not even add a new keyword.
Ignore or any more keywords are bad and I also think that the correct
would be hide(ing). But as I further more explained it should
really be
something that only marks a method as private if at all. That can be
done as:
'foo as private' since private is a keyword it cannot conflice
anyway.
I like this solution.
Yes to me it seems like we can solve the entire lack of
encapsulation through aliasing/hiding by making the following changes
to the original proposal:
A trait may contain methods and properties. When importing a trait
into a class, all methods and properties are imported in a way that
makes them only visible within the trait (I dont like the use of
private here .. its what confused me in the first proposals of this
approach by Marcus/Andi). The user of the trait can however explicitly
make properties and methods from the trait visible to the class
importing the trait. Also the trait using class can explicitly say
that it wants to override a method/property in the scope of the trait.
This way:
1) there is little chance of accidentally breaking a trait
2) changes within the trait should not break anything in the trait
using class, unless the developer explicitly messed with the traits
internals in the class using the trait. in that case however he can
quickly spot the potentially problematic lines
I have been uncomfortable with the current trait suggestions because
they occur in the body of the class, whereas extends/implements is
outside. I think there is a way to handle this, however.
I dont agree here. traits are different. They do not affect what the
class is. They change what it can do and as such the stuff should be
defined next to properties and methods.
?php
trait trait1 { function a(){}}
trait trait2 { function a(){}}
class Blah extends ... implements ... traits trait1, trait2, trait3 {
}
?
Here it gets worse. Now if I refactor things into a trait, I have to
start changing all uses of those methods.
@Greg: I think you are going in the wrong direction here.
Fun that you mentionned that structure greg because I was thinking of
something along those lines. Something very similar actually but the
aliasing could look like this:
trait One {
function name() { return __TRAIT__; }
function removeMe() {}
}
trait Two {
function name() { return __TRAIT__; }
}
class Reel traits One, Two
{
override One::name with Two::name;
remove Two::removeMe;
It is of course
remove One::removeMe;
}
$object = new Reel();
echo $object-name(); // Echos Two of course.
I find that rather clean and clear that you we are either overriding
what with what and then removing a method. But as lukas mentionned, we
may be stepping out of line here...
regards,
Lukas
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David,
Re-read what you are replying.
--
David,
Re-read what you are replying.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] nettiquette on this mailinglist
On Fri, Feb 22, 2008 at 10:41 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hello all, Let me briefly pick on poor David's (unfortunately I could have picked any number of posts on any given day just as well) recent emails [1] [2]: they are prima example of very bad quoting. Again I do not expect everybody to read through the mailinglist README [3] from cover to cover. Especially not the linked RFC [4]. However if you do not at least skim over it, please use some common sense. Every millisecond spend making your post high quality will probably safe hours on a global scale. Thank you and I will try not to o too crazy with posts like this. I might come up with one every few months if things get out of hand too much. But hopefully the current posters will educate all future posters indirectly by being role models :) Sorry for the noise .. regards, Lukas [1] http://marc.info/?l=php-internalsm=120369441121012w=2 [2] http://marc.info/?l=php-internalsm=120369445521127w=2 [3] http://ch2.php.net/reST/php-src/README.MAILINGLIST_RULES [4] http://www.faqs.org/rfcs/rfc1855.html -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Well well well, sorry everyone. I'm just too cool to follow the rules :) Just kidding, I guess I will change email client and apply my signature to myself as well :) Good that you mentioned that Lukas, I know I am not the only internal (? Can I say that?) that does bad replies and breaks the mailing list etiquette (I do not even mention some of our favorite users/posters). Just hope that this will whip some air and move people around. Sure moved me. -- David, Re-read what you are replying... david -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Multi-threading
On Wed, Feb 20, 2008 at 10:36 PM, Felipe Ribeiro [EMAIL PROTECTED] wrote: Hello, I've been reading this list for a couple of months and I have a question that might have already been discussed here before and I haven't seen, so please apologize me. My question is if there's any intent to have multi-threading support to PHP in a future version, like PHP7. I know multi-threading is an enormous source of bugs, but I think it does offer a good support for large-scale apps considering the background processes and event-driven programming, and also allowing the apps to be self-content with no needs and no dependency of external daemons like cron. I have spoken to a few people lately about this and to be honest, the opinion I get out of multi threading in php is basically no one cares doing it, no internals need it so badly that he'll implement it, and find people to maintain it Opening this thread is a good idea I think, after this I'll gather all ideas and comments and make a good post out of it. So, what's the opinion of the PHP maintainers? Regards, -- Felipe Ribeiro [EMAIL PROTECTED] http://feliperibeiro.com 83 9979-3161 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Role model RFC
On Feb 19, 2008 2:09 PM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: Hi, I really like what Stefan did here with his traits RFC. Very solid work, even if there are still some people not convinced if they want this feature in, I have seen little complaints about the way this proposal was made. Quite the contrary actually. I would like this kind of detailed thought to become more the norm. Even if at the very beginning of an idea this quality may not be immediately attainable, it should be the goal. So for every idea we should have at least someone who tries to bring the proposal to this kind of level as the discussions progress. Most definitely, thanks to Stefan for this. I have rarely seen such RFC in PHP lately. This is.. wow, from simple example to a bit more complex and real life examples, simple texts, the reason why we need this and a bit more about MI. The external links to further readings on the subject are great and the thesis is even better (A bit long but very interesting). I think this can make a lot of good to PHP's RFC process if handled correctly. Let's just hope we do it correctly :) For this proposal I would hope that it would be put on some host we can trust to not disappear and be updated with the feedback. I am still dreaming of a php.net wiki for this kind of stuff. If interested I do of course offer wiki.pooteeweet.org to host these RFC's for the time being. Using php.net/reST has the draw back of requiring cvs.php.net karma for maintenance, which would be problematic for new comers, unless we can do karma on a per file level for this? Wiki is such a great idea, what were the (political?) reasons for not having it ? No one to maintain it ? regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David, Re-read what you are replying. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Math functions (new parameter parsing)
On Feb 12, 2008 9:08 PM, Felipe Pena [EMAIL PROTECTED] wrote: Em Qua, 2008-02-13 às 01:31 +0100, Pierre Joye escreveu: Hi! On Feb 13, 2008 1:04 AM, Felipe Pena [EMAIL PROTECTED] wrote: Hi all, I made a patch for 5_3 where all functions in ext/standard/math.c use the new parameter parsing. (As was done in HEAD) I think it got lost between you and the list :) If anyone think it good, let me know, and then i'll commit it. Several tests break with the patch. Hence, i'll fix them also, if agreed. :) How do they fail? I worry a bit about BC here. There are two cases. In most part of it: 003+ Warning: acos() expects exactly 1 parameter, 2 given ... 003- Warning: Wrong parameter count for acos() ... And breaking BC: 010+ 011+ Warning: acos() expects parameter 1 to be double, string given ... 012+ NULL 010- float(1.570796327) 014+ 015+ Notice: A non well formed numeric value encountered ... PS: The same behavior in HEAD. http://felipe.ath.cx/diff/math.diff Thanks for your work! Thanks for your attention! :) -- Regards, Felipe Pena. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php As long as it's in 5_3 I believe there'll be no problems. I did the same for a few string.c functions. As long as the behavior itself doesn't change, I'd say good work :) -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18
Re: [PHP-DEV] [patch] expose PHP version details as constants
On Feb 8, 2008 7:52 AM, Pierre Joye [EMAIL PROTECTED] wrote: Hi, Testing the PHP version can be much easier and faster if the versions details were exposed via the constants, like what we use internally. This little patch expose what we have in php_version.h #define PHP_MAJOR_VERSION 5 #define PHP_MINOR_VERSION 2 #define PHP_RELEASE_VERSION 6 #define PHP_EXTRA_VERSION -dev #define PHP_VERSION 5.2.6-dev already available as contant #define PHP_VERSION_ID 50206 Patch against 5.2 attached. Any objections? Bla bla bla.. Commit the thing already :)) Cheers, -- 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 -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] get_magic_quotes_gpc, get-magic-quotes-runtime in head, get a final decision
+1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in pcre (pcre.backtrack_limit)?
On Jan 30, 2008 4:03 PM, Karl Pflästerer [EMAIL PROTECTED] wrote: Felipe Pena [EMAIL PROTECTED] writes: Hello Em Qua, 2008-01-30 às 20:57 +0100, Karl Pflästerer escreveu: Hi, when pcre.backtrack_limit is reached with preg_replace() the subject string gets truncated to a string of length zero. I changed the phrase about the return value (3 weeks ago) in pcre_replace(), it can be seen at http://docs.php.net/preg-replace, i added or NULL if an error occurred. ?php ini_set(pcre.backtrack_limit,10); $s = str_repeat(a, ); var_dump(preg_replace(/a(.*?)b/, \$1, $s)); var_dump(preg_last_error()); // 2 = PREG_BACKTRACK_LIMIT_ERROR Output: NULL int(2) Thanks for the explanation; sadly your addition can only be found at docs.php.net not for example at www.php.net/manual/en/function.preg-replace.php which was until now my first choice if i wanted to look something up in the docs. For future information Karl, http://docs.php.net is the main documentation server. Everything else are mirrors and those will be regenerated around the release of php 5.3 (Not now..) :) IMO this is the wrong behaviour but it's at least documented :-) KP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18
Re: [PHP-DEV] Re: re-proposal of pecl/phar for inclusion in core
On Jan 28, 2008 2:09 PM, Steph Fox [EMAIL PROTECTED] wrote: phar's zip support. The tests simply need to be modified to create the zips using pecl/phar and copy the filename to one phar doesn't already know about, and the failures will go away. I thought you wanted 'pure' zips for the tests - that told me! So how do I create a zip with ext/phar then, other than by using convertToZip()? - Steph Greg -- 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 Just as a side note. I have been following Phar development closely since basically the beginning of the project and I must admit that despite being an advocate and user of this piece of code, over the past few months, Greg has put up a LOT of effort and wonderful commits. I personally have been impressed by his C skills that I was not aware of before. This said, I believe that phar can be used widely by many many projects and that anyone using java and jar files have the right to be awful jealous about the phar in php. Anyways, thanks greg you have made my life much easier with the strike of commits and optimizations + features you have added to phar. I want it in core, want it now. Thanks Greg and Marcus a bunch (once again) -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: voting
On Jan 12, 2008 9:57 AM, Gregory Beaver [EMAIL PROTECTED] wrote: Lukas Kahwe Smith wrote: Hi, I think its painfully obvious that a system to manage the voting is needed. Like I said, ideally it should also have an email interface. People should be able to vote from +1 to -1 and be able to add a comment. Notifications should be send to this list about the start and final result of the vote. Voting itself should be split by people with access to cvs.php.net and those that do not. This is open source, everybody can voice their opinions, but the developers of the project should have final say. However if the end user and developer votes diverge greatly it will still be an important hint to take into account. That being said, end user polling imho belongs somewhere else and before the final developer vote. The features of PEPr in PEAR cover all of this quite well, except for the email interface. I personally would not need that and maybe its too much of a hassle to get this done in a reliable and secure way. PEPr, unfortunately, is very tightly bound to the pearweb code, and would be a big hassle to separate as it currently stands. We have been working (by we, I mostly mean Helgi) for over a year now trying to clean up pearweb and still are only about halfway through the codebase, but when PEPr is tackled, I will let you all know. Of course, if there is someone enterprising who wants to assist with that specific part of the cleanup, the code is in cvs at pearweb/. PEPr-specific code is located in pearweb/include/pepr, pearweb/public_html/pepr, and pearweb/cron/pepr.php. And if that entrepreneur-person needs tips about the pearweb code or mentoring, I'll be glad to help. Thanks, Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mailinglist rules
On Jan 11, 2008 4:45 AM, Lukas Kahwe Smith [EMAIL PROTECTED] wrote: On Jan 10, 2008, at 8:57 PM, Lukas Kahwe Smith wrote: On Jan 10, 2008, at 4:55 PM, Antony Dovgal wrote: On 10.01.2008 18:33, Derick Rethans wrote: On Thu, 13 Dec 2007, Gregory Beaver wrote: We don't need moderation, we don't need read-only. We need people to follow a simple common-sense checklist. It's either that nobody saw this mail, or chose to ignore it. Obviously, nothing changed and I'm getting sick and tired of all this crap on internals, so here once more: We need to put this checklist somewhere and point to it each time the list starts to overfill again. http://www.php.net/reST/ seems to be the best place for it. I will put something there soon, loosely based on Greg's post. I will likely ask for some quick feedback in #php.pecl and of course it can be tweaked further later .. I have made a first commit: http://cvs.php.net/viewvc.cgi/php-src/README.MAILINGLIST_RULES?view=markup It should show up at the above mentioned URL in a while too. Note I quickly wrote this up and asked for some feedback on IRC. Typo fixes and either be fixed directly in CVS or mailed to me off list. Anything controversial should discussed in this thread or on IRC .. you know the base line rules now :) regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Great stuff Lukas, good move -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Square brackets shortcut
On Jan 10, 2008 2:40 PM, Andi Gutmans [EMAIL PROTECTED] wrote:
I think next time Sam has three consecutive responses to the same thread
then he loses access to the list for a week :) (same rule for anyone
else). Tweaking the 'Subject' won't count as a different thread :)
Andi
-Original Message-
From: Hannes Magnusson [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 10, 2008 6:49 AM
To: Sam Barrow
Cc: PHP Development
Subject: Re: [PHP-DEV] [RFC] Square brackets shortcut
Did you know that you don't have to reply multiple times to the same
post?
And even though Stas replies to every single post, you don't have to
do
it too.
Please read Andis checklist again;
http://news.php.net/php.internals/34494 - same rules apply to all
threads.
-Hannes
On Jan 10, 2008 3:37 PM, Sam Barrow [EMAIL PROTECTED] wrote:
I just tried this out using option b, and I really like it.
$var = [1, 6, 434] ;
I think it looks good and helps code readability alot.
On Thu, 2008-01-10 at 19:07 +0900, Ryusuke SEKIYAMA wrote:
Hello, lists,
I'm tired to type array() many times. And I want to
declare arrays more easily. So I wrote the patch for
zend_language_parser.y which enables to declare arrays
with square brackets like some other languages.
Stanislav,
Sorry, I'm new in this list and I didn't know about past
discussion. As Marcus says, I'd like to ask around again.
There are three options:
a) Commit square bracket array shortcut patch
keys and values are separated by colons.
( http://www.opendogs.org/pub/php-5.3dev-080109-sbar.patch )
e.g.
$a = [1, 2, 3];
$b = ['foo': 'orange', 'bar': 'apple', 'baz': 'lemon'];
b) Commit square bracket array shortcut patch
keys and values are separated by double arrows.
( http://www.opendogs.org/pub/php-5.3dev-080109-sbar2.patch )
e.g.
$a = [1, 2, 3];
$b = ['foo' = 'orange', 'bar' = 'apple', 'baz' = 'lemon'];
c) Reject and keep using `array()'.
e.g.
$a = array(1, 2, 3);
$b = array('foo' = 'orange', 'bar' = 'apple', 'baz' =
'lemon');
These patches include the tests.
Which do you like? I like (a) the best.
Regards,
2008/1/6, Marcus Boerger [EMAIL PROTECTED]:
Hello Stanislav,
tha makesw three then already, how about we ask around again?
Ryusuke, can you please start a new '[RFC] Square brackets
shortcut' thread
to collect opinions and pass along the patch for that?
I like the anonymous function patch too. It is clean and simple.
Maybe you
want to start a second '[RFC] Anonymous functions' thread with
that patch.
Can you also please add tests for both?
marcus
Wednesday, January 2, 2008, 7:51:06 PM, you wrote:
the square bracket array syntax patch for PHP 5.3,
http://www.opendogs.org/pub/php-5.3dev-080101-sbar.patch
I remember we discussed that already and it was rejected then
(even
though myself and Andi liked it) - did the people that
objected
then
change their minds?
Best regards,
Marcus
--
/**
* Ryusuke SEKIYAMA
* [EMAIL PROTECTED]
*/
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
If you want reasons just ask me privately, as Pierre said, no need to argue :)
-1
D
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting
On Jan 7, 2008 1:34 PM, Sam Barrow [EMAIL PROTECTED] wrote:
On Mon, 2008-01-07 at 13:33 -0500, Robert Cummings wrote:
On Mon, 2008-01-07 at 19:21 +0100, Stefan Priebsch wrote:
Sam Barrow schrieb:
Keep in mind that your do_whatever would actually be a trigger error
with an error message including the name of the function and parameter
number.
I did not make the point of my code clear enough. do_whatever is not the
code that triggers the error, but the code that handles the error.
My point is that I think people will start checking parameters before
they call a function to avoid a fatal error. This is more code and
uglier, because you'll have to repeat it for every function call,
instead of once in the function body.
Even if they put an explicit typecast into a function call, like
foo((int) $something) error handling code would have to be provided in
case the cast was not possible.
This is an optional feature. It's MY library, why can I not force
consumers of the API to use it how I, the developer, think it should be
used?
The onus should be on consumers of my API to use it properly, not on me
to jump through hoops to make sure they gave me the correct data at
every step of the way. I stopped holding hands in grade 3 or so.
True. It would also keep the APIs more tightly integrated, and
interaction less prone to type errors.
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I believe the cleanest solution that we could implement would be using
the type casting with Type objects.
Just like java, php could have internally something as follow:
$int = new Integer(3);
$string = new String(3);
$double = new Double(3.231);
That way, we could easily do such:
class Foo
{
public function fooString(String $stringValue)
{
// wan wan... we want an int now...
return $string-parseInt();
}
public function fooInteger(Integer $intValue)
{
// Wan wa we want a string back!
return $int-toString();
}
// ...
}
This is of course very easily implementable in user land code,
however, if we would put it internally, it would give the ability to
anyone who wants to use it to use it correctly to use it (broad usage)
The mentioned method would be used only by people who need type
hinting and they would be using ONLY the good types in their functions
since the only thing they could pass is an instantiation of the
desired data type.
Since people seem to be very scared about not being able to convert
this and that, we could provide methods as such as
$int-toString();
$string-parseInt();
etc.
This would not differentiate from using it as
(int)$int;
(string)$string;
But it would give much flexibility and OO Behaviors.
People would do not want to use it just don't use it, and people who
wish to use it could.
I remember Hannes posted a simple implementation for userland on this
very same internals list, I think it was clean and simple to use.
Performance wise.. hey, if one has a dying wish of using OOP concepts,
he's probably willing to loose a bit of performance to maintainability
and strictness-ity? and having strong typed applications.
$0.02...
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl_autoload vs __autoload
On Dec 31, 2007 6:06 PM, Greg Beaver [EMAIL PROTECTED] wrote: Marcus Boerger wrote: Hello Johannes, I agree with Pierre here. How about finally making SPL built in always like ext/standard? +1 Finally... +1 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] spl_autoload vs __autoload
On Dec 28, 2007 6:56 AM, Andrew Mason [EMAIL PROTECTED] wrote: Hi guys, Can anyone shed some light on the advantages of the spl_autoload over the standard __autoload ? is there any ? Please use php-general for that kind of question. kind regards Andrew -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __autoload proposal
On Dec 22, 2007 3:43 PM, Wojciech Malota [EMAIL PROTECTED] wrote:
I have a proposal for prototype of __autoload function in PHP 5.3.0.
In this version of PHP namespaces will be available.
Prototype of __autoload could look like this:
__autoload($classname, $namespace = null);
Now __autoload have only one argument which is a name of searched class.
Second argument could be a namespace where class is searched. It should have
default value for backward compatibility.
For example:
?php
namespace Space1::Space2;
class A {
public function Test() {
$b = new B; // Class B isn't known at this moment
}
}
?
When user try to create new object of unknown class B __autoload function
should be called with parameter $classname = 'B' and $namespace =
'Space1::Space2'
but int this example:
?php
namespace Space1::Space2;
class A {
public function Test() {
$b = new Space3::Space4::B; // Class B isn't known at this moment
}
}
?
Arguments should be: $classname = 'B' and $namespace = 'Space3::Space4';
I think it is the most flexible solution. It allows to create very useful
and effective mapping mechanisms.
--
Wojciech Ma³ota
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Patch ?
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Re: [PHP-DEV] namespace improvements to be committed very soon - final review
On Dec 11, 2007 6:42 PM, David Coallier [EMAIL PROTECTED] wrote:
On Dec 11, 2007 6:13 PM, Gregory Beaver [EMAIL PROTECTED] wrote:
Hi,
I've been furiously working behind the scenes with Stas and Dmitry, and
have some enhancements to namespaces in the form of 2 patches.
1) multiple namespaces per file
2) use ::name;
1) multiple namespaces per file
This is implemented as such:
?php
namespace one;
use Blah::A;
// code
namespace two;
use Foo::A;
?
The example above shows that imported names are reset at each namespace
declaration. There is no prohibition on this code:
?php
namespace one; {
use Blah::A;
// code
}
namespace two; {
use Foo::A;
// code
}
?
namespace name; {
...
}
??? You can already do that... it's just adding random { }
Users who wish to use brackets may do so. The performance penalty
imposed by using brackets is minor for some cases, and for users who are
following the recommended practice of 1 namespace per file, the syntax
is ideal.
Patch is:
http://pear.php.net/~greg/namespace/PHP_5_3/multi.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/multi.patch.txt
Note that non-namespaced code cannot be present in a file containing
namespaces. For users who are bundling, this will mean you will need to
create 2 files, one with non-namespaced code, and one with namespaced
code. This minor prohibition is a design decision, not a technical
problem in the implementation.
2) use ::name
This code:
?php
namespace Whatever;
use MDB2; // import PEAR's ::MDB2 from global scope
$a = MDB2::connect();
?
is currently impossible, which will make namespacing old code harder.
The patch introduces this new syntax to import names from the global
namespace:
?php
use ::MDB2, ::strlen as len;
?
http://pear.php.net/~greg/namespace/PHP_5_3/use.patch.txt
http://pear.php.net/~greg/namespace/PHP_6_0/use.patch.txt
These patches are for review of both serious technical and serious
implementation issues. In order to help move things along, I'd like to
define serious as something directly related to the implementation
that would cause a failure in PHP's ability to run scripts
deterministically, or some kind of memory leak/crash.
commit is planned for the next 24 hours or so, but of course any issues
found in review can be fixed. The patches are short, so in the worst
case, reverting is not difficult.
Thanks,
Greg
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Wow even nested namespaces are implemented!!!
namespace name;
{
{
{
class Test { }
}
}
}
...
use name as superName;
var_dump(new superName::Test());
Come on...
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] RFC: Dropping Namespace
On Dec 4, 2007 5:41 PM, Steph Fox [EMAIL PROTECTED] wrote:
Hi D,
extension (DateTime, DateTimeZone). However introducing the new class
DateTimeSpan might break people's code that do things like:
?php
use myNamespace::DateTimeZone as DateTimeZone;
?
Typo? I guess you meant 'DateTimeSpan' to be in there somewhere...
This is I think the biggest problem with the implementation, that new
internal classes can still break userland code. The problem of single-file
namespacing is only a problem because of the performance implications for
those who bundle their includes, and it _should_ be possible to find a good
way to resolve that. I don't really see a problem with the 'use only at the
head of the file' thing (although I know others do); in fact I prefer it,
because it makes for an easier upgrade path.
Can I just ask one thing? If namespace support is once again pulled before
it sees the light of a release, can we _please_ document exactly what the
problems were, loud and clear, and put the document somewhere people are
likely to see it?
Thanks,
- Steph
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I never thought it would get back to the drawing board that way, but
Derick, as I said on irc when we discussed about that, I agree with
you. With the current implementation, the namespaces should be removed
completely. Not only because it has missing features, but from the
voice that comes out of the community, it seems that some features
(important ones) (Point 2) and some PHP general concept (Point 3) are
simply not what people want.
I do not want to start a flamewar here, but again, the { } thread came
up a few days ago and again, everyone who says that they get a
performance gain by aggregating the files (Like compiled PHP files)
are being either ignored or in some way insulted... Anyways, some
people do not believe in the aggregation of the files, why's that ? I
am not quite sure, well I have a few ideas but they are not
appropriate for the mailing list, but the optimization technique that
is aggregating the files work and I would really love to see it stay
(At least the ability to decide if I want to aggregate them or not).
And this is currently not possible with the implementation.
Things like use * as * is something that is missing and a very
important feature to my eyes as well. However, this kind of feature
comes with education. If we allow people to use * as *, we have to
explain them that the namespaces are not going to be coding for you.
They might introduce the same conflicting errors as before when they
had only classes. I want to make sure people understand that
namespaces are not there to make one type less but as a great man once
said, an additional structural element that is to be used correctly in
order to work correctly.
(You can give a nail to someone and he'll stick it in his eye instead
of building a house... but if you show him how to use the nail
correctly and with which other tools, he'll be able to build something
solid... maybe...)
From what I have experienced since the namespaces are in, my prefixing
is still the way to go to make sure I can run all my nifty
optimization scripts around and make a few free optimizations.
This is a thread that will probably go deep in the sand in a few days
(unless the community arises (which doesn't usually happen)) but for
the records, if anyone has anything to say, it's still the time :)
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] people.php.net
You mean something like http://pear.php.net/map ? On Dec 3, 2007 12:44 PM, Rasmus Lerdorf [EMAIL PROTECTED] wrote: I have some new code for it. I'll try to find some time to update it over the next couple of weeks. -Rasmus Silvano Girardi Jr wrote: Gentleman, This morning I went to see Lukas speaking at the Brazilian PHP Conference and he mentioned http://people.php.net He said that it started with the idea to map the PEAR developers. I went to see it but the project seems to be stuck. Also, I was trying to find out on the mailings what you guys have already discussed about it but I have found nothing. Google shows only Antony asking on his blog if the idea died even before it was born :P I am starting a project here that could fit on the people.php.net so I'd like to know who is currently responsible for that and what I can do to help or perhaps assume it so we can have it moving forward. For those that saw the [EMAIL PROTECTED] and is wondering who I am, I have my account since 2005 when I put in the PEAR Validate_ptBR package but did not make more contributions since then. I'd like to get back with contributions and make my account worth. Regards, Silvano Girardi Jr. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Unable to compile PHP6 with pgsql
On Dec 1, 2007 10:45 AM, Michael Eshom [EMAIL PROTECTED] wrote: I should also mention that I haven't done anything with C in probably 5 or 6 years, but if you're willing to help me out, I'll see what I can do :) Antony Dovgal wrote: On 30.11.2007 04:43, Michael Eshom wrote: Wish I could help, but I don't know what needs to be done or how to go about doing it. That's no problem, we can show what to do =) -- Michael Eshom Christian Oldies Fan Cincinnati, Ohio I'd say start with that :) http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE?revision=1.9view=markuppathrev=HEAD, http://cvs.php.net/viewvc.cgi/php-src/README.UNICODE-UPGRADES?revision=1.17view=markuppathrev=HEAD, http://cvs.php.net/viewvc.cgi/php-src/unicode-gotchas.txt?revision=1.1view=markuppathrev=HEAD :) -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- 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
On Nov 29, 2007 12:49 PM, Steph Fox [EMAIL PROTECTED] wrote: So, what, exactly, is the fuss all about? Richard, the problem with a CLA (moral quibbles apart) is it prevents any of the core contributors doing anything with the code. As in: +# PDO Specs. CLA required to commit +unavail||pdo-specs That's what 'unavail' means. Surely all this us/them, silence behind doors, etc., is just FUD? Show me where there's been any open discussion and I'll agree with you. If IBM, or anyone, wants to submit code to PHP it can only improve things. Sure, but if IBM, or anyone, wants to prevent the people who work on the PHP core from touching that code don't you think there might be a teensy bit of an issue there? We do have peer-review after all. Not on CLA'd code we don't. - Steph -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Ok this is driving me nuts: http://url.ie/730 or http://tinyurl.com/2242cf (They are both going to the same place but some people have preferences) -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
On Nov 18, 2007 5:52 PM, Cristian Rodriguez [EMAIL PROTECTED] wrote:
2007/11/18, Derick Rethans [EMAIL PROTECTED]:
I am actually thinking that it might be a good thing to add more and
more. I know my quick hack isn't the best implementation though.
Yes and it is an alternative and not a mandatory thing to use.. as long as :
?php
function foo(int $num) {
return $num
}
foo(12345) // emit fatal error, NOT accept it as valid integer
all is fine and Im all for it ;)
--
http://www.kissofjudas.net/
I was thinking at something along the lines of objects also for instance:
$i = new Integer(33);
function foo(Integer $var) {
}
foo ($i); else it emits a fatal error. But also if you do
$i = Name; that would emit a fatal error because the value is
suposed to be an int. This might look a bit too much like java, but as
an extension it could be something quite interesting I believe.
String, Object, Integer, Scalar, Float and what else.
So thinking of something like
$string = new String(Foo);
$string = bar or $string-setValue(Bar); would do
$float = new Float(4.242);
$float-setValue('foobar'); // That emits an error
$float-setValue(3.14159);
echo $float; (__toString) or echo $float-getValue; to echo it's content/value
and so on.
Would that be too java-ish to be something considered in php6 ? ;-)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
On Nov 18, 2007 7:24 PM, Hannes Magnusson [EMAIL PROTECTED] wrote:
On Nov 19, 2007 12:13 AM, David Coallier [EMAIL PROTECTED] wrote:
I was thinking at something along the lines of objects also for instance:
$i = new Integer(33);
function foo(Integer $var) {
}
foo ($i); else it emits a fatal error. But also if you do
$i = Name; that would emit a fatal error because the value is
suposed to be an int. This might look a bit too much like java, but as
an extension it could be something quite interesting I believe.
String, Object, Integer, Scalar, Float and what else.
So thinking of something like
$string = new String(Foo);
$string = bar or $string-setValue(Bar); would do
$float = new Float(4.242);
$float-setValue('foobar'); // That emits an error
$float-setValue(3.14159);
echo $float; (__toString) or echo $float-getValue; to echo it's
content/value
and so on.
That has got to be the worst idea I've heard on internals for over a month.
Besides, you can do this in userland already anyway:
haha :) Yes, you can do many things in userland.
?php
class InvalidTypeException extends Exception {}
class UnknownTypeException extends Exception {}
class Types {
const INTEGER = 1;
const FLOAT = 2;
const STRING = 3;
const OBJECT = 4;
const BOOLEAN = 5;
private $val, $type;
public function __construct($val, $type) {
$this-type = $type;
$this-setValue($val);
}
public function setValue($val) {
switch($this-type) {
case self::INTEGER:
if (!is_int($val)) {
throw new InvalidTypeException;
}
break;
case self::FLOAT:
if (!is_float($val)) {
throw new InvalidTypeException;
}
break;
case self::STRING:
if (!is_string($val)) {
throw new InvalidTypeException;
}
break;
case self::OBJECT:
if (!is_object($val)) {
throw new InvalidTypeException;
}
break;
case self::BOOLEAN:
if (!is_bool($val)) {
throw new InvalidTypeException;
}
break;
default:
throw new UnknownTypeException;
}
$this-val = $val;
}
public function getValue() {
return $this-val;
}
public function __toString() {
return (string)$this-getValue();
}
}
class Integer extends Types {
public function __construct($val) {
parent::__construct($val, Types::INTEGER);
}
}
class String extends Types {
public function __construct($val) {
parent::__construct($val, Types::STRING);
}
}
class Float extends Types {
public function __construct($val) {
parent::__construct($val, Types::FLOAT);
}
}
class Object extends Types {
public function __construct($val) {
parent::__construct($val, Types::OBJECT);
}
}
class Boolean extends Types {
public function __construct($val) {
parent::__construct($val, Types::BOOLEAN);
}
}
function type_hint_integer(Integer $val) {
echo $val, \n;
}
function type_hint_string(String $val) {
echo $val, \n;
}
function type_hint_float(Float $val) {
echo $val, \n;
}
type_hint_integer(new Integer(123));
type_hint_string(new String(string));
type_hint_float(new Float(0.25));
Nice implementation, so ? Still more code to include in your code.
Anyways, the Optional part in the subject means ... optional. Which
means that it does not *have* to be used and that the default hinting
will still be loose.
That gives the chance to anyone to use either strongly-typed code or
loosely-typed code. You know as much as I do that it's quite easy to
do (implement - like you just did), but if it's not in by default,
people won't care about doing it or implementing it.
On the other hand, if it's there, some people might be tempted to use
it, and will. But hey.. php's a loosely typed language and it'll
definitely stay that way. But only giving the choice to someone to use
what he feels like is quite interesting in my opinion.
Anyways, no need to get all grumpy, you can just say you don't like
the idea, that'll do just as well. Anyways, that was a thought, it's
quite easy to implement as an extension
Re: [PHP-DEV] [PATCH] Optional scalar type hinting
We actually had spoken of that on irc a few times and a while ago, the answer I got back was basically, If you want java, use java... On Nov 16, 2007 8:40 PM, Cristian Rodriguez [EMAIL PROTECTED] wrote: 2007/11/15, Sam Barrow [EMAIL PROTECTED]: I found a patch by Derick online to allow for scalar type hinting, and made it work with the newest snapshot of PHP 5.3. IIRC Hannes had a patch to implement this the right way, but unfortunately it has not been merged. . Hopefully he can publish an updated version somewhere because I agree that having this functionality is a good thing. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Question about Core inclusion
On Nov 10, 2007 5:27 PM, Stanislav Malyshev [EMAIL PROTECTED] wrote: Hey there all, over the past few days I was thinkering over something that I consider could be a good addition to the core or actually to the php distribution. PhpSecInfo, the project by Ed Finkler. I was But isn't it a set of PHP scripts? If so, what would be the value of making it an extension? There are a lot of very useful PHP scripts, which aren't part of core PHP. Yes there are a lot of very useful packages, but I think this one could be very good but not only for the users but also php's general security image/reputation. Yes many settings can be set in a way that make PHP less safe than what it can be and helping our users getting towards a more secure application and dev process would be optimal and very cool. Simple in ext/ where one could go like --enable-security-info But yeah, I won't be mad if we decide it's a bit useless for the core but I think it would be a good feature add for PHP6 and perhaps even a bit of press coverage about php's security, but good press :P -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Question about Core inclusion
Hey there all, over the past few days I was thinkering over something that I consider could be a good addition to the core or actually to the php distribution. PhpSecInfo, the project by Ed Finkler. I was thinking in making that an extension that we could distribute with the distribution so the same way someone has access to phpinfo() he'd have access to phpsecinfo(); to show all the security warnings from it's php.ini and server settings. So my question is, is the effort worth it or it's sure to be refused ? If people seem interested that's cool, if not that's cool too. I just thought it might be a great way to help people resolve some simple security problems due simply to their configuration. Let me know what you all think, Thanks, D -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] T_IMPORT - T_USE; [ZEND-ENGINE-CVS] cvs: ZendEngine2 / zend_compile.c zend_compile.h zend_language_parser.y zend_language_scanner.l
Good stuff On 11/6/07, Sebastian Nohn [EMAIL PROTECTED] wrote: Dmitry Stogov wrote: Hi, I'm going to commit the same patch into PHP_5_3 tomorrow. Thanks a lot! - Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Patch] http_fopen_wrapper.c and allowing any response code w/o warning
On 11/2/07, Jared Williams [EMAIL PROTECTED] wrote:
Yes, had fun with trying to use http php streams ... Imo, 2xx status codes
should always be considered succesful.
I personally do not consider all of them to be right but I also
think they should be cosnidered successful, since they are.
http://bugs.php.net/bug.php?id=36947
http://marc.info/?l=php-internalsm=111384113712112w=2
J
-Original Message-
From: David Zülke [mailto:[EMAIL PROTECTED]
Sent: 01 November 2007 23:10
To: PHP Internals
Subject: Re: [PHP-DEV] [Patch] http_fopen_wrapper.c and
allowing any response code w/o warning
This is probably better:
if (options STREAM_ONLY_GET_HEADERS ||
(php_stream_context_get_option(context, http, ignore_errors,
tmpzval) == SUCCESS Z_BVAL_PP(tmpzval))) {
- David
Am 02.11.2007 um 00:06 schrieb David Zülke:
Hi folks,
I've recently played with CouchDB, which is a document
database with a
RESTful HTTP interface.
I noticed, however, that there is no way to prevent PHP
from throwing
a warning on response codes other than 200, 206, 301, 302 and 303.
Something like 201 Created throws a warning, for example.
But I'm not sure if simply adding that one to the list is
the proper
way forward, as I imagine there are many situations when
you just want
to get the response content and look at the headers afterwards (w/
stream_get_meta_data). So I looked at the code and came up
with this
change for http_fopen_wrapper.c line 547
(http://lxr.php.net/source/php-src/ext/standard/http_fopen_wrapper.c#5
47
):
if ((options STREAM_ONLY_GET_HEADERS) ||
(php_stream_context_get_option(context, http, ignore_errors,
tmpzval) == SUCCESS Z_TYPE_PP(tmpzval) == IS_BOOL
Z_BVAL(retval))) {
So when the option ignore_errors is set for HTTP on the
context, no
error will be thrown, and the response body is returned properly.
Is that a reasonable idea? I'm not entirely sure about the
ignore_errors name, maybe someone has a better suggestion.
I'd be happy to supply a full patch, but I wanted to hear if anyone
has thoughts on this first.
Cheers,
David
--
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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
Re: [PHP-DEV] PHP 5.3 RM / PHP 5.2.5RC1
On 9/29/07, Ilia Alshanetsky [EMAIL PROTECTED] wrote: I spoke to Johannes and few other core developers and I think it is time we give someone new a shot at the helm. I've been doing 5.X RMing since 5.0.3 (almost 2 years now, seems like forever) and its time for some fresh perspective, I think 5.3 will prove a good time for that to keep with our tradition of changing RMs on every minor release. We have well documented (Thanks to Lukas) RMing processes now that should make the bureaucracy ;-) a little simpler and I feel Johannes definitely has enough technical awareness of the various parts of PHP to do a great job at the RM role. Unless any objections are raised, or someone else wants to throw their hat into the mix, I'd like to confirm Johannes at his new role as 5.3 RM and wish him the best of luck and much co-operation from all developers. In the mean time, I will continue to RM the 5.2.X release, which will continue to be actively maintained up until 5.3 is released and use this opportunity to provide 2 week notice of the upcoming 5.2.5RC1, so please, get your pending fixes in. The goal is get 5.2.5 out early/ mid November. Thanks for all that work Ilia, and congrats to you Johannes Ilia Alshanetsky 5.2 Release Master -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] mail.force_extra_parameters
On 9/12/07, Stanislav Malyshev [EMAIL PROTECTED] wrote: Would anyone object to disallowing setting mail.force_extra_parameters from .htaccess? The problem is that mail.force_extra_parameters can pass arbitrary arguments to mail tool, and some mail tools (especially one, guess which ;) have a lot of parameters, that allow, in particular, reading and writing arbitrary files - which may be a problem with safe_mode (yes, I know, but we are still in 5.x) and open_basedir. I understand that mail.force_extra_parameters was meant for sysadmins anyway, so disallowing .htaccess to change it seems ok. Objections? -- You definitely got a +1 from me for the exact same reasons, it's for sysadmins and if you have that in your .htaccess I believe this is a problem. 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 -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] multiple namespace per file
On 9/11/07, Larry Garfield [EMAIL PROTECTED] wrote:
On Tuesday 11 September 2007, Marcus Boerger wrote:
Hello Stanislav,
Tuesday, September 11, 2007, 1:21:07 AM, you wrote:
Hi!
Following the feedback from the community, we (mostly me and Dmitry)
tried to find a good model that would allow multiple namespaces per file
without running into too many problems and complications, and would
allow to bundle multiple namespaced files together without
modifications. It looks like it is possible to do, but only under the
following condition: the file can have multiple namespaces, but if the
file has namespaces, then it can have no code outside namespaces.
For example, this would work:
namespace A;
class X {}
namespace B;
class Y {}
This looks very messy. We should either go with curly braces or with one
namespace at the top of a file. And even if we do multiple namespaces per
file. I guess we do not allow a naespace to be spread onto several files,
right?
From a readability-usability perspective (which is all I am able to offer),
I'd have to agree with Marcus. The syntax should follow the structure of the
parser. So either:
?php // One namespace per file only
namespace Foo;
class X {}
function bar() {}
?
or
?php // Multiple namespaces permitted
namespace Foo {
class X {}
}
namespace Baz {
function bar() {}
}
I agree that allowing stuff in a file outside of a namespace if namespaces are
used would be all kinds of confusing with either syntax.
--
Larry Garfield AIM: LOLG42
[EMAIL PROTECTED] ICQ: 6817012
If nature has made any one thing less susceptible than all others of
exclusive property, it is the action of the thinking power called an idea,
which an individual may exclusively possess as long as he keeps it to
himself; but the moment it is divulged, it forces itself into the possession
of every one, and the receiver cannot dispossess himself of it. -- Thomas
Jefferson
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Most of us do agree, but Stas specifically specified that this is not
a { } thread :)
--
David Coallier,
Founder Software Architect,
Agora Production (http://agoraproduction.com)
51.42.06.70.18
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP_FALIAS()
On 9/10/07, BuildSmart [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 10, 2007, at 08:53:29, Marcus Boerger wrote: Hello BuildSmart, If you have the correct includes in place, sure. marcus Thanks for the response, OK I think I can manage that with ease, what I'm contemplating to do is create a mysql_alias extension that aliases the mysql extension functions to the mysqli equivalents since a lot of scripts and packages are already dependent on the mysql extension but it's been deprecated (so I've been informed) and I was thinking of a simple method to allow the dropping of the mysql extension in favor of the mysqli extension without having to rewrite existing scripts and packages. Since you claims it's possible to alias an external extensions functions I guess it's just a matter of getting the includes worked out and what headers need to be loaded in the faking module. This will probably require a little finessing but shouldn't be too difficult or complicated. Actually if you look at zend_API.h which contains ZEND_FALIAS (PHP_FALIAS /main/php.h) you'll notice that as long as the includes are done, it's quite trivial to do :) Good luck, Saturday, September 8, 2007, 11:36:15 AM, you wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I've seen several examples of PHP_FALIAS within a single module, I'm wondering if it's possible to have one module with aliases referencing functions in another module? - -- Dale -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG4m0P0hzWbkf0eKgRAmlXAKChGWEIl+Hz9uOFVFv76qddNH0T5wCeIllB VsN5vneLwIMBXwBTSEzSbH0= =fw4n -END PGP SIGNATURE- Best regards, Marcus - -- Dale -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2 (Darwin) iD8DBQFG5Uc00hzWbkf0eKgRAomHAKCegTASJWoqwHi+szmDwiXU82wVdQCgqzBT uf2junm3kDfwnOZzDTnCKOI= =+07f -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHAR was PHP 5.3 Suggested Feature List
On 9/10/07, Andi Gutmans [EMAIL PROTECTED] wrote: Yes, I will ask Dmitry to share it with you. There's huge value in having a standard format which existing tools can already manipulate. It doesn't have to be tar but IMO it should be something standard. Andi -Original Message- From: Gregory Beaver [mailto:[EMAIL PROTECTED] Sent: Monday, September 10, 2007 2:08 PM To: Andi Gutmans Cc: PHP Developers Mailing List Subject: Re: [PHP-DEV] PHP 5.3 Suggested Feature List Andi Gutmans wrote: 14) Link phar extension from PECL into core (possibly enabling it by default) 1 0 -1 -1 (I'd prefer a standard format which can be manipulated with standard tools (also some tests we did with TAR format we got much better performance). In general though the use-case should be clear as I don't think Web apps are the real target here)) Care to share how you benchmarked? I found an exponential performance improvement when I moved from tar to the current file format. Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Andi, if there was to be a cross platform tool to view, extract, add, etc with phar archives, would that influence your choice ? Thanks, -- David Coallier, Founder Software Architect, Agora Production (http://agoraproduction.com) 51.42.06.70.18 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
