Re: [PHP-DEV] CVS to SVN Migration
Rasmus Lerdorf schrieb: Lukas Kahwe Smith wrote: The git and hg integration with svn is also good so any developer who prefers to have a local repository can very easily use either git or hg and easily merge into the central svn repository. However I think we should provide the infrastructure for developers to setup a dvcs. I dont know if we want to standardize on a specific one. But collaboration on exterimental stuff that requires a dvcs should be possible on php.net servers. What do you mean by that? hgsvn and git-svn don't need any server-side support to enable you to work locally and do local git or hg checkins and then sync to the central svn repository when you are ready. -Rasmus It should not be a question of product, but of workflow. An example: A lot of time is needed when porting bugfixes from a stable branch to the development branch and vice versa. In my experience a DVCS reduces this time immense. PHP-SRC consists of a lot of branches (and tags) and the goal should be to port code as easy as possible between different branches. Using a DVCS which is based on a direct acyclic graph (short DAG) can change the way you work with a VCS. Probably most of you who have worked with a DVCS know the technique of DaggyFixing (http://www.venge.net/mtn-wiki/DaggyFixes). Basically it means that a Bugfix is not committed to the revision where it is fixed, instead the Bugfix Graph is inserted right after the feature where the problem occurred and then the merge is propagated to the head revision. If you take SVN and export it locally to a DVCS, then do some coding and reimport your patches, this advantages are probably lost (though I have to admit that I never tried it). Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Hello Lars, for an ambitious userland developer it is not very easy to follow this list and even join the discussions (though I think it's worth). Maybe there should be a point where some discussions from internals should be taken to lang - better not this one, I don't want to fuel the fire again - but some discussions really should. But this is a matter of process, especially extracting the results and save it at a place that is more accessible and persistent than the mailing list archives. This process should not imply that what's proposed there should be realised - in the end the core developers have to make the final decision. This process should be an decision helper for all core developers who are undecided. Sebastian Lars Strojny schrieb: Hi Sebastian, Am Freitag, den 30.05.2008, 18:23 +0200 schrieb Sebastian Deutsch: [...] Nonetheless I feel that the userland is less represented on the internals list - do you have a proposal to hear their voice? Well, they can subscribe, can't they? http://www.php.net/mailing-lists.php cu, Lars
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Johannes Schlüter schrieb: On Thu, 2008-05-29 at 13:32 -0700, Chris Stockton wrote: My only question, is what does PHP want. When I say PHP, of course I am referring to the tens-of-thousands of users that make PHP a success. Lets remember that random commenters which I would like to refer to as PHP's actual user base, which I would further annotate that the committers graciously power, respectively; In general tend to favor introducing the syntax. So, if you were to apply that ratio to the tens(hundreds?) of thousands of people actually using PHP 50:50 Well, the commiters become commiters since they show continuing interest in PHP and spent time to learn about the internals and made experiences for taking the consequences from bad decisions. There are non-commiters here which are really smart and probably have way more experience than many others around here but many of the commenters here seem not to be of that kind, some say hey, that's fancy new stuff I want it but don't think about any consequences ... I simply assume that the amount of these people is less in the commiters group, and well, it are the commiters who will, most likely, maintain the engine over the nextfew years, non-commiters come and go on this list more frequently. Besides the clue factor there's another point: Most Contributors do stuff _they_ need and by chance users get it, too. That in the hope that others contribute, too and create stuff the other one uses. For most people there's not much reason to maintain stuff they don't need all they get is a bigger ego. If a user wants a feature he should step up Oh, and I like that posting from another project's list about that topic: http://lists.freebsd.org/pipermail/freebsd-current/2007-April/070607.html I have been watching the mailing list for long as I can remember and seems that features and such are never truly voted for. Perhaps a PHP.net voting system should be made, so PHP can progress based off what the community wants, not what a group of committers want. I Voting? Oh my. I don't agree to all stuff in the book, but in general it's a good read: http://producingoss.com/html-chunk/consensus-democracy.html respect fully the time and effort put into the project but time to time I see the vote of PHP (in the afore mentioned context) lost and discounted for. Generally speaking: Why should somebody develop and maintain a feature for free he doesn't want? If a user wants a feature they should prove that they will maintain it in the longer run and provide a patch. Most stuff in PHP was done since the contributors needed it themselves So back to the original topic: In a 50:50 scenario I'd certainly give more weight to people I know for contributing for a long time than somebody who just appeared on the list. That's what I said in my previous mail. johannes Hello, I updated the RFC collecting all pro and contra arguments and finally put it under declined: http://wiki.php.net/rfc/shortsyntaxforarrays I also added a conclusion section - feel free to add stuff here. I also re-added the Discusssion on the Web section, because it reflects what the user base is thinking on this topic. For all those who were thinking, that this vote was senseless: Please use RFC if a new user askes for this feature again - IMHO this is better than referring him to the archives of the list. Maybe it also provides deeper understanding in the decision making process. Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Philip Olson schrieb: I also re-added the Discusssion on the Web section, because it reflects what the user base is thinking on this topic. This section of random blogs is unnecessary especially considering how open the lists are to the world. I consider this section to be a bad If I want my voice really heard I'll post a blog entry instead of this list, and I'll even get a link out of the deal precedent. Regards, Philip Hello Philip, if it hurts so much I will remove that section. Nonetheless I feel that the userland is less represented on the internals list - do you have a proposal to hear their voice? Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
I think a public voting system is not a good thing (though the idea appealed me in the first place) - but I was convinced that it would lead to vote without discussion. For listening to the user base I originally had a headline Discussion on the Web were I refered to some blog posts covering that topic. Actually someone removed it by Discussion on the List. Jonathan Bond-Caron schrieb: It's a big +1 for me and this sums it up PHP is about building on the knowledge and experience of the typical target user. This target user changes slowly as we all get older and the industry we are in changes and we need to recognize that and adapt the language appropriately. What is appropriate is of course a really hard call which is what this is all about. My first concern about the [] debate is no one is really asking what the users want? Where did the [] requirement or proposal come from? There's no doubt in my mind that a [] synthax is something most users would want. The similar array declaration to javascript also further reinforces the use of PHP for web based programming. Finally, having a public voting system would definitely help gain more insight as to what users want. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Short syntax for array literals [...]
Andi Gutmans schrieb: Not sure we really reached a conclusion. I think it was inconclusive and people got tired. As I've stated in the past in general I don't like the ability to do things in more than one way but in this case I think the advantages of the cleaner syntax outweigh the fact that we'd have two ways. I'd prefer to support [] but I don't think it's a huge deal if we don't do it. It would make PHP a bit nicer :) Andi can I take this one as a +1? Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Short syntax for array literals [...]
Stanislav Malyshev schrieb: please add your votes I'm +1. BTW - how hard would it be to add voting interface to the wiki? I don't think it's hard: http://wiki.splitbrain.org/plugin:poll http://wiki.splitbrain.org/plugin:userpoll Sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problem with Namespaces
Hello, I'm currently fooling around with the new namespaces feature. Is there any (semi) official documentation when to use use or import. use Foo; Warning: The use statement with non-compound name 'Foo' has no effect in. Is there any additional information. cheers *.sebastian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with LSB
Hello, that's it. Even $b = new B; $b-foo(); // echos B - good works. Thank you! *.sebastian Sebastian Deutsch schrieb: Hello, care... my case is slightly different. I was aware of that problem, but in my case I call B::foo() from the main scope - it behaves right - when I call it within the scope of C (same call) it behaves different. This is different as described in the bug. The same call should have the same output, not depending of the scope where I call it. Sebastian Lokrain schrieb: Hello, Sebastian This seems to be a known bug http://bugs.php.net/bug.php?id=43408 and in fact already assigned. Fallbacks occur in static/self calls, as static/self resolve to foo and it returns foo as expected. However, when you do a parent::demo() you actually call bar::demo(), which is currently understood as a fully qualified call: the caller is not passed. There are plans to allow explicit parent call to pass the caller, but this is *still under discussion*. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Problems with LSB
Hello, care... my case is slightly different. I was aware of that problem, but in my case I call B::foo() from the main scope - it behaves right - when I call it within the scope of C (same call) it behaves different. This is different as described in the bug. The same call should have the same output, not depending of the scope where I call it. Sebastian Lokrain schrieb: Hello, Sebastian This seems to be a known bug http://bugs.php.net/bug.php?id=43408 and in fact already assigned. Fallbacks occur in static/self calls, as static/self resolve to foo and it returns foo as expected. However, when you do a parent::demo() you actually call bar::demo(), which is currently understood as a fully qualified call: the caller is not passed. There are plans to allow explicit parent call to pass the caller, but this is *still under discussion*. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Problems with LSB
Hello,
i've written the following code using Etiennes LSB. But I'm facing some
problems.
?php
class A {
function foo() {
echo get_called_class();
}
}
class B extends A {
}
class C {
function moo() {
B::foo();
}
}
B::foo(); // echos B - good
$c = new C;
$c-moo(); // echos C - wtf?? should be B
?
Is it a bug, or did I miss anything?
Sebastian Deutsch
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: __call_static() Magic Method
Hello,
where can i find the latest version of your patch?
Etienne Kneuss provided me a patch to track from where my class method
is called statically.
?
class foo {
function doit() {
echo get_called_class();
}
}
foo::doit(); // with etiennes patch it will echo foo
?
Will they work together?
cheers
*.sebastian deutsch
Sara Golemon schrieb:
Attached is a patch which exports an internals hook in zend_class_entry
for fetching function pointers similar to the object hook get_method()
available to instance methods.
This patch also exports a userspace hook __call_static() which operates
in the fashion of the current __call() magic method, but for static calls.
Wez called for some functionality like this a few weeks ago for a COM
wrapper (or something similar), and I noticed there was actually a
comment in the engine about how this should eventually be done anyway...
Usage example:
class foo
{
public static function __call_static($fname, $args)
{
echo foo::{$fname}() called staticly with ,
count($args), parameters\n;
}
}
foo::randomMethod(1,2,3);
I considered setting get_static_method to zend_std_get_static_method()
by default (avoiding the if set check during runtime), but all the other
hoooks follow this pattern so I went with consistency.
If noone comments to the negative, I'll commit next friday (7/20)...
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] late static binding php6
hello, is there a patch for the proposal out there? is anyone working on that problem? cheers sebastian deutsch -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
