On 17/07/09 8:31 AM, Davey Shafik wrote:
...
More importantly, the branch/merge support in SVN is limited to
temporary feature/bug branches. You branch, *complete* the feature/bug
fix, and then merge it in. After that, if you decide to carry on in your
branch, SVN's merge tracking cannot handle
On 17/07/09 12:24 PM, Lukas Kahwe Smith wrote:
...
also using merge tracking is only fun if everybody does it .. because if
only some people use it .. they first have to figure out which things
have not been merged via svn merge, as svn merge updates its metadata.
when merging you can either
On 16/07/09 3:45 PM, shire wrote:
...
Do we have a long-term plan of using actual merge commands/tools to
merge our branches rather than duplicating commits or manually merging?
I think this could speed up development and allow us to have more
control over releases, versions, etc. I've seen
Aside: I'd like to propose an internals-specific mutation of Godwin's
law, which might state:
As a PHP internals discussion thread grows longer, the probability of a
comparison involving Perl 6 approaches 1.
JG
On 07/07/09 6:14 PM, Wez Furlong wrote:
-1 for 5.x
+1 for 6.0
Otherwise the
On 07/07/09 10:17 AM, Andrei Zmievski wrote:
Andrei Zmievski wrote:
I would like to ask all developers to voice their opinions of whether
it makes sense to add this to 5.3 or to throw it away (either one is
fine btw). To keep the process simple flamewar free, please
restrict yourself to +/-
On 12/17/08 4:29 PM, jay wrote:
hi guys. i'm very new to your list so maybe something similar to my
proposal has been already posted somewhere at this list but really i
don't know how i can make the search.
i often pass arrays to functions/methods this way:
myfunc(array('key1'='val1',
Rasmus Lerdorf wrote:
And my stance hasn't changed either:
http://marc.info/?l=php-internalsm=117060700805108w=2
...
+1
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Antony Dovgal wrote:
...
Well, to me it matters whether the author is going to care of the thing he's
proposing or he's going to disappear right after it's implemented.
I didn't realize there was a section of the code flagged 'syntactic
sugar' and only a few people maintained that part. it
Gregory Beaver wrote:
Jeff Griffiths wrote:
Antony Dovgal wrote:
...
Well, to me it matters whether the author is going to care of the
thing he's proposing or he's going to disappear right after it's
implemented.
I didn't realize there was a section of the code flagged 'syntactic
sugar
Antony Dovgal wrote:
On 01.10.2007 16:32, Ilia Alshanetsky wrote:
This was not on the table and the time of the 5.3 discussion, I for
one think its a bit too much magic.
Yeah, too Perl-ish for me.
Actually, it's a lot like Python list slicing, which is a great feature
and a clear enough
chris# wrote:
On Tue, 10 Jul 2007 19:30:26 -0500, Larry Garfield [EMAIL PROTECTED] wrote:
...
The claim that is still repeated
that one has to rewrite everything to be OO in order to port to PHP 5
is,
quite simply, FUD.
True. But then again, what's the point of using 5 if you're not
Tijnema wrote:
On 7/11/07, Jeff Griffiths [EMAIL PROTECTED] wrote:
...
- file_get_contents()
PHP 4 = 4.3.0, PHP 5
D'oh! Thanks for the history lesson.
- simplexml / DOM parsing / libxml2
- json_encode|decode
JSON PECL extension can be installed for PHP = 4.3.0
It *can
Richard Lynch wrote:
On Wed, July 11, 2007 4:40 pm, Tijnema wrote:
Except for the OO, I don't see anything that can't be done in PHP4,
while it can be done in PHP5. Some workarounds are maybe needed, but
it mostly doesn't require more than 10 lines of PHP code extra.
The SOAP / XML stuff is
13 matches
Mail list logo
