Well, this is all OK. I guess, even if it means PHP will remain messy
for more years yet.
But can someone point me as to why this (backwards) choice has been made?
On 11/22/05, Rowan Lewis <[EMAIL PROTECTED]> wrote:
> Well, this is all OK. I guess, even if it means PHP will remain messy
> for mor
download
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Well no, I guess you don't want to, but then do you want to keep
adding new features following no specific naming method? Users I know
of already complain about the lack of standard naming throughout PHP.
As there are already alot of changes in PHP6, would it really hurt
more to change to one stan
On Tue, 22 Nov 2005, Rowan Lewis wrote:
> Well no, I guess you don't want to, but then do you want to keep
> adding new features following no specific naming method?
Bullshit, we have guidelines for that:
http://cvs.php.net/annotate.php/php-src/CODING_STANDARDS?rev=1.32#84
> As there are already
Perhaps this has already been proposed and I missed it as I'm new to the
list, but why not set a release in the future, say PHP8, in which there
will be no holds barred about breaking bc? Everyone would know that this
upcomming release would be the one that resolves all inconsistencies with
lots of
i would agree with you matt :)
--
Joseph Crawford Jr.
Zend Certified Engineer
Codebowl Solutions, Inc.
1-802-671-2021
[EMAIL PROTECTED]
Hello folks!
On 11 and 12 November a bunch of us had a developers meeting in Paris,
discussing the things we want to do for PHP 6. Partly because of the
Unicode support, but we also discussed the items on "Rasmus' wishlist"
and a lot of other items. I made a report of the discussions we had and
Hello all,
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was _THE EXACT SAME ONE_ that my patch uses.
To add insult to injury, it's mentioned that Marcus was going to pro
On Tue, 22 Nov 2005, Jessie Hernandez wrote:
> I saw the notes regarding namespaces, and it really suprised me that the
> namespace patch was not looked at in detail, discarded, and then the approach
> that was agreed on was _THE EXACT SAME ONE_ that my patch uses. To add insult
> to injury, it's
Jessie Hernandez wrote:
I saw the notes regarding namespaces, and it really suprised me that the
namespace patch was not looked at in detail, discarded, and then the
approach that was agreed on was _THE EXACT SAME ONE_ that my patch uses.
To add insult to injury, it's mentioned that Marcus was
On 11/22/05 11:12 AM, [EMAIL PROTECTED] wrote:
Perhaps this has already been proposed and I missed it as I'm new to the
list, but why not set a release in the future, say PHP8, in which there
will be no holds barred about breaking bc? Everyone would know that this
upcomming release would be the o
Hi Rasmus,
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:
"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Then we saw an
Jessie Hernandez wrote:
The way the sentence was worded at
http://www.php.net/~derick/meeting-notes.html#name-spaces led me to
believe this:
"First we briefly discussed the current name space patch, but as we were
not all familiar with its workings we did not go into deep detail for
this. Th
Rasmus Lerdorf wrote:
The entire meeting was exclusively about PHP 6. We are too far along in
the 5.1 process to make any large changes at this point.
Actually, I did not mean to include it in the current 5.1 version (as
that's about to be released), but I was hoping for it to make it in
Hello Jessie,
Tuesday, November 22, 2005, 7:57:47 PM, you wrote:
> Rasmus Lerdorf wrote:
>>
>> The entire meeting was exclusively about PHP 6. We are too far along in
>> the 5.1 process to make any large changes at this point.
>>
> Actually, I did not mean to include it in the current 5.1 ve
Hello Derick,
Tuesday, November 22, 2005, 7:26:56 PM, you wrote:
> On Tue, 22 Nov 2005, Jessie Hernandez wrote:
>> I saw the notes regarding namespaces, and it really suprised me that the
>> namespace patch was not looked at in detail, discarded, and then the approach
>> that was agreed on was _
Great, I have been waiting for this list sine Derick mentioned the
meeting in his talk at the conference :)
@Derick: There have been some questions and issues raised during your
talk... Dou you remember them? It was about reading from files with the
new unicode semantics, and you said these were s
Matthias Pigulla wrote:
2.10 Dynamic class inheritance
Can someone elaborate a little on what this is supposed to be ;)?
Also known as runtime inheritance, or late binding. It's not a new
thing, we have it today. The discussion was about whether to have a way
to disable this and force peo
Now that was a quick reply :)
> Also known as runtime inheritance, or late binding. It's not a new
> thing, we have it today. The discussion was about whether to
> have a way
...
That is, one can write
if (...) class A extends X {} else class A extends Y {}
right now? Seriously ;)?
Every
Matthias Pigulla wrote:
Now that was a quick reply :)
Also known as runtime inheritance, or late binding. It's not a new
thing, we have it today. The discussion was about whether to
have a way
...
That is, one can write
if (...) class A extends X {} else class A extends Y {}
right now?
Marcus,
I agree that we should work together on this, so that we can achieve the
best result possible and to avoid duplicate work. To a certain degree,
we have already worked together on this, when you suggested using the
__autoload mechanism to resolve namespace imports and this is what I
en
Hi.
Section 2.4 conclusion 2 of
http://www.php.net/~derick/meeting-notes.html indicates that:
> We make "var" an alias for "public" and remove the warning for it.
Despite the lateness, if it is agreed that this should be done, can it
not be fast-tracked into 5.1? It would be very much welcome if
> I don't see why you can't specify that a class definition must have a
> constructor. Obviously the constructor is not for the
> interface itself.
Ok, that is, having __construct in the interface asserts that everything
you get passed (as an implementation of the interface) has been
constructe
Hello Matthias,
Tuesday, November 22, 2005, 9:22:16 PM, you wrote:
>> 2.10 Dynamic class inheritance
> Can someone elaborate a little on what this is supposed to be ;)?
Binding static members at run time rather than compile time. See the notes
for an example that shows the difference. Usage exa
Hello Matthias,
Tuesday, November 22, 2005, 10:29:09 PM, you wrote:
>> I don't see why you can't specify that a class definition must have a
>> constructor. Obviously the constructor is not for the
>> interface itself.
> Ok, that is, having __construct in the interface asserts that everything
5.4 Late static binding using "this" without "$" (or perhaps with a
different name)
The same example, but now with the call to "self::static2()" replaced with
"static::static2()", will then print "B::static2".
Using static::func() is a bit corny, I understand why you don't want another
new keywo
Hello Bob,
Wednesday, November 23, 2005, 1:44:53 AM, you wrote:
> 5.4 Late static binding using "this" without "$" (or perhaps with a
> different name)
> The same example, but now with the call to "self::static2()" replaced with
> "static::static2()", will then print "B::static2".
> Using stat
Here's an idea for the maintainer of the Reflection API, to be able to view
the class a method is defined in (if not overridden).
class Vehicle {
function go() {}
function crash() {}
}
class Car extends Vehicle {
function crash() {}
function collectInsurance() {}
}
class Ford ex
Whoops, that memcmp should be a strcmp.
> -Original Message-
> From: Bob Silva [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 22, 2005 8:19 PM
> To: 'internals'
> Subject: [PHP-DEV] Reflection API idea
>
> Here's an idea for the maintainer of the Reflection API, to be able to
> view
29 matches
Mail list logo
