At 12:55 AM 3/23/2004 +0100, Edin Kadribasic wrote:
On Tuesday 23 March 2004 00:13, Marcus Boerger wrote:
you may consider me responsible for this mess - i must admit i forgot about
sqlite's oo api a long time ago since it is running...(i know lame excuse)
Obviously if we're going for
On Tue, 2004-03-23 at 03:01, Andi Gutmans wrote:
order to minimize the damage caused by changing to studlyCaps, I suggest we
make the changes now and roll an RC2 within a week. At least this way,
people who are starting to pick-up PHP 5 due to its RC status will not have
to change their
At 03:43 AM 3/23/2004 -0500, John Coggeshall wrote:
On Tue, 2004-03-23 at 03:01, Andi Gutmans wrote:
order to minimize the damage caused by changing to studlyCaps, I
suggest we
make the changes now and roll an RC2 within a week. At least this way,
people who are starting to pick-up PHP 5 due
I agree with Marcus (and I think Andi) here. If its not too much trouble OO
interface to mysqli should IMHO follow the same conventions other OO
extensions do,
beside changing c-code it's
- changing documentation (english, german, spain and french)
- changing all samples
- changing testcases
On Tuesday 23 March 2004 11:58, Georg Richter wrote:
I agree with Marcus (and I think Andi) here. If its not too much trouble
OO interface to mysqli should IMHO follow the same conventions other OO
extensions do,
beside changing c-code it's
- changing documentation (english, german, spain
Hi,
For a few weeks I am looking for contact to organizators
of the PHp Conference in Amsterdam. I would like to register
for conference, but I can't.
During the registration phase one need to typ VISA number etc.
This is odd to me, and my University want to pay just with a bank
transfer.
For a
On Mar 23, 2004, at 6:52 AM, Edin Kadribasic wrote:
On Tuesday 23 March 2004 11:58, Georg Richter wrote:
I agree with Marcus (and I think Andi) here. If its not too much
trouble
OO interface to mysqli should IMHO follow the same conventions other
OO
extensions do,
beside changing c-code it's
-
As one of the authors who is trying to hit this moving target, I don't
think how an API change in PHP 5 is going to mess up something in my
book should be a factor in deciding if it should be done. It is annoying
as all hell, but last I checked PHP doesn't revolve around publishers
and their
i'm with georg. then again, i never quite agreed with all your base is
belonging to studlycaps, its a nice guideline for future code, but i
don't see the the necessity of breaking old stuff, even if it hasn't
been released yet, its been in the tree for well over a year.
-sterling
On Mar 23,
What about using the old names as aliases for the new ones,
triggering deprecation warnings when called?
--
Ferdinand Beyer
[EMAIL PROTECTED]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Tuesday 23 March 2004 16:23, Ferdinand Beyer wrote:
What about using the old names as aliases for the new ones,
triggering deprecation warnings when called?
Don't you think its a bit silly to keep BC with something that hasn't even
been officially released yet? Depriciated things in the
First of I do not believe it is a good idea this late in the release cycle to
change the API of the SQLite's OO interface, especially without a fallback
mechanism. This change obsoletes all existing articles, tutorials, etc... and
will definitely break scripts of early adopters, which would
On Tue, 23 Mar 2004, Markus Fischer wrote:
On Tue, Mar 23, 2004 at 04:23:12PM +0100, Ferdinand Beyer wrote :
What about using the old names as aliases for the new ones,
triggering deprecation warnings when called?
+1 on this. This doesn't break those authors examples, at least not
On Mon, 22 Mar 2004, Andi Gutmans wrote:
What would you expect? That if a new style constructor is defined we always
use that and allow old-style as regular method?
Yep.
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Mar 23, 2004, at 11:53 AM, Andrei Zmievski wrote:
On Mon, 22 Mar 2004, Andi Gutmans wrote:
What would you expect? That if a new style constructor is defined we
always
use that and allow old-style as regular method?
Yep.
I agree with the part about the new-style constructor always being
On Tue, 23 Mar 2004, George Schlossnagle wrote:
I agree with the part about the new-style constructor always being
preferred to the old-style constructor, but besides being really
confusing, where do you being able to call the old-style as a regular
method coming in handy?
I don't really.
On Tue, 23 Mar 2004, George Schlossnagle wrote:
On Mar 23, 2004, at 11:53 AM, Andrei Zmievski wrote:
On Mon, 22 Mar 2004, Andi Gutmans wrote:
What would you expect? That if a new style constructor is defined we
always
use that and allow old-style as regular method?
Yep.
I
Rasmus Lerdorf wrote:
I could see people doing:
class foo {
function foo() {
...constructor stuff...
}
function __construct() {
$this-foo();
}
}
Why not just leave out __construct in this case? Or am I missing
something? This looks pretty ugly to me. And if you
On Tue, 23 Mar 2004, Ferdinand Beyer wrote:
What about using the old names as aliases for the new ones,
triggering deprecation warnings when called?
NO.
- Andrei
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Rasmus Lerdorf wrote:
I could see people doing:
class foo {
function foo() {
...constructor stuff...
}
function __construct() {
$this-foo();
}
}
I actually prefer it the other way around... foo would call __construct in
PHP4, and __construct would be
I'm +1 for the change, if that means anything :)
Sure, your book isn't ready yet. Would be interesting to know your opinion if
it would be printed already.
And for closing the discussion:
we had a) feature freeze and b) I removed EXPERIMENTAL
and therefore I will not change it.
Cheers!
On Tue, 23 Mar 2004, Brad Fisher wrote:
Rasmus Lerdorf wrote:
I could see people doing:
class foo {
function foo() {
...constructor stuff...
}
function __construct() {
$this-foo();
}
}
I actually prefer it the other way around... foo
On Mar 23, 2004, at 1:11 PM, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Brad Fisher wrote:
Sure, but George was asking for a case. I think the case where you
have
some existing PHP4 code that you want to make minimal changes to but
you
might have a little bit of PHP5-specific code to run in
RL Sure, but George was asking for a case. I think the case where you have
RL some existing PHP4 code that you want to make minimal changes to but you
RL might have a little bit of PHP5-specific code to run in the constructor I
RL could see this sort of chaining being something people want. I
On Tue, 23 Mar 2004, Stanislav Malyshev wrote:
RL Sure, but George was asking for a case. I think the case where you have
RL some existing PHP4 code that you want to make minimal changes to but you
RL might have a little bit of PHP5-specific code to run in the constructor I
RL could see
PHP 4 Bug Database summary - http://bugs.php.net
Num Status Summary (765 total including feature requests)
===[*Directory/Filesystem functions]
27609 Feedback is_writable returns true for file that can not be written to
--- Georg Richter [EMAIL PROTECTED] wrote:
Sure, your book isn't ready yet.
Is this really the criteria being used to support a lack of consistency?
This sort of thing (inconsistency) is one reason why PHP is frequently
attacked and why developers consider various APIs to be unintuitive. We
On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote:
--- Georg Richter [EMAIL PROTECTED] wrote:
Sure, your book isn't ready yet.
Is this really the criteria being used to support a lack of
consistency?
This sort of thing (inconsistency) is one reason why PHP is frequently
attacked
and
Is this really the criteria being used to support a lack of consistency?
This sort of thing (inconsistency) is one reason why PHP is frequently
attacked and why developers consider various APIs to be unintuitive. We
should pick a standard, any standard, and stick to it. I dislike
StudlyCaps
Tuesday, March 23, 2004, 8:32:51 PM, you wrote:
Is this really the criteria being used to support a lack of consistency?
This sort of thing (inconsistency) is one reason why PHP is frequently
attacked and why developers consider various APIs to be unintuitive. We
should pick a standard, any
On Tue, 2004-03-23 at 12:58, Georg Richter wrote:
Sure, your book isn't ready yet. Would be interesting to know your opinion if
it would be printed already.
Then I really wouldn't care. In either case, this entire thread is
getting completely pointless. I don't care if studlyCaps or
Hello John,
Tuesday, March 23, 2004, 9:05:51 PM, you wrote:
On Tue, 2004-03-23 at 12:58, Georg Richter wrote:
Sure, your book isn't ready yet. Would be interesting to know your opinion if
it would be printed already.
Then I really wouldn't care. In either case, this entire thread is
Marcus Boerger wrote:
I already changed SQLite because as far as i know there were only two
extensions left which didn't follow studlyCaps convention which we agreed
upon twice so far - even though ppl pretend we hadn't. The only other
extension i spotted so far not following studlyCaps is ming -
At 09:16 AM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, George Schlossnagle wrote:
On Mar 23, 2004, at 11:53 AM, Andrei Zmievski wrote:
On Mon, 22 Mar 2004, Andi Gutmans wrote:
What would you expect? That if a new style constructor is defined we
always
use that and allow
At 09:16 AM 3/23/2004 -0800, Rasmus Lerdorf wrote:
I agree with the part about the new-style constructor always being
preferred to the old-style constructor, but besides being really
confusing, where do you being able to call the old-style as a regular
method coming in handy?
I could see
At 11:12 AM 3/23/2004 -0800, Sterling Hughes wrote:
On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote:
--- Georg Richter [EMAIL PROTECTED] wrote:
Sure, your book isn't ready yet.
Is this really the criteria being used to support a lack of consistency?
This sort of thing (inconsistency) is one
Hi,
what about just changing ext/tidy
back to underscore_methods?
Afaik I proposed that in a private mail to you months ago, cause you changed
it after feature freeze when tidy was not in an experimental state. But you
didn't reply :(
Changing everything after an announced feature freeze
We had a compile-error which I changed to E_STRICT :)
I think we should make __construct the default if it is present.
Andi
At 08:42 PM 3/23/2004 +0100, Marcus Boerger wrote:
Hello Andi,
Monday, March 22, 2004, 11:24:03 AM, you wrote:
What would you expect? That if a new style constructor is
On Tue, 23 Mar 2004, Georg Richter wrote:
Changing everything after an announced feature freeze sucks. It's just
ignoring others (users, authors and publishers) - a loss of face. Obviously
some people like this kind of policy - me not!
I do agree with this. There is no point in announcing
At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Georg Richter wrote:
Changing everything after an announced feature freeze sucks. It's just
ignoring others (users, authors and publishers) - a loss of face.
Obviously
some people like this kind of policy - me not!
I do
Hello Andi,
Tuesday, March 23, 2004, 10:24:09 PM, you wrote:
We had a compile-error which I changed to E_STRICT :)
I think we should make __construct the default if it is present.
that'd be great.
marcus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote:
At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Georg Richter wrote:
Changing everything after an announced feature freeze sucks. It's
just
ignoring others (users, authors and publishers) - a loss of face.
Obviously
On Tue, 23 Mar 2004, George Schlossnagle wrote:
On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote:
At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Georg Richter wrote:
Changing everything after an announced feature freeze sucks. It's
just
ignoring others
At 01:41 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, George Schlossnagle wrote:
On Mar 23, 2004, at 4:30 PM, Andi Gutmans wrote:
At 01:24 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Georg Richter wrote:
Changing everything after an announced feature
On Tue, 23 Mar 2004, Andi Gutmans wrote:
So call it RC2. The name is irrelevant. The important part is to let
people know that there are some big code-breaking changes happening and
that just because a freeze and an RC was announced nobody should count on
features and functions being frozen
At 01:48 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Andi Gutmans wrote:
So call it RC2. The name is irrelevant. The important part is to let
people know that there are some big code-breaking changes happening and
that just because a freeze and an RC was announced nobody
On Tue, 23 Mar 2004, Andi Gutmans wrote:
At 01:48 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On Tue, 23 Mar 2004, Andi Gutmans wrote:
So call it RC2. The name is irrelevant. The important part is to let
people know that there are some big code-breaking changes happening and
that just
We decided on studlyCaps a while ago and I wasn't aware people here
didn't apply this decision.
Hmm, looks like I was on vacation when decision was made. I only can remember
that we agreed BEFORE feature freeze, to have studylCaps when the underlying
api also supports it (like xml stuff).
ps issue
there are no other basic issues. They are all bug fixes.
Ok, if you are sure of that fine. But lets doublecheck with the
authors
of the main new components (sqlite, mysqli, simplexml) first and make
sure
they are all in sync. For example, Derek Ford's simplexml-related
message
to
Hello Sterling,
Tuesday, March 23, 2004, 11:41:24 PM, you wrote:
ps issue
there are no other basic issues. They are all bug fixes.
Ok, if you are sure of that fine. But lets doublecheck with the
authors
of the main new components (sqlite, mysqli, simplexml) first and make
sure
they
On Mar 23, 2004, at 1:17 PM, Andi Gutmans wrote:
At 11:12 AM 3/23/2004 -0800, Sterling Hughes wrote:
On Mar 23, 2004, at 10:54 AM, Chris Shiflett wrote:
--- Georg Richter [EMAIL PROTECTED] wrote:
Sure, your book isn't ready yet.
Is this really the criteria being used to support a lack of
Hello internals,
after SQLite's commit ~16hours ago i was reminded that i have violated
vertain rules - not change something while in release process and not
changing api's of non experimental extensions.
I must admit i knew this before but i was in a conflict and i am still.
The conflict is
My take and a bit of a clarification for Andi. I wasn't criticizing you
personally, I was criticizing the Release Manager which happens to be you.
Admittedly the distinction is subtle. The RM's job is to heard cats.
You take input from everyone and make a decision on when to freeze and
when
On Mar 23, 2004, at 6:48 PM, Marcus Boerger wrote:
As you know my actings started a long discussion and now i am
questioning:
Are we following our rules and decisions? And if so which
rule/decision do
ppl want me to follow? The one i did which potentially hurts some
article
writers? Or the
On Tue, 2004-03-23 at 17:24, Rasmus Lerdorf wrote:
Ok, if you are sure of that fine. But lets doublecheck with the authors
of the main new components (sqlite, mysqli, simplexml) first and make sure
they are all in sync. For example, Derek Ford's simplexml-related message
to internals last
On Tue, 23 Mar 2004, Andi Gutmans wrote:
Huh? Now you're really going to confuse people. You can always have RC2 and
more.
Yeah, but changing whole APIs between RCs is just not Ok. I mean,
changing those things Before an RC, a la... but it's jut too late now; a
lose of face as Georg already
On Tue, 23 Mar 2004, John Coggeshall wrote:
On Tue, 2004-03-23 at 17:24, Rasmus Lerdorf wrote:
Ok, if you are sure of that fine. But lets doublecheck with the authors
of the main new components (sqlite, mysqli, simplexml) first and make sure
they are all in sync. For example, Derek
On Tue, 23 Mar 2004, Rasmus Lerdorf wrote:
they are all in sync. For example, Derek Ford's simplexml-related message
to internals last week(*) worries me somewhat. He passed on what looks to
be some basic brokeness in the extension which nobody has addressed so
far.
(*)
On Mar 23, 2004, at 11:21 PM, Adam Maccabee Trachtenberg wrote:
On Tue, 23 Mar 2004, Rasmus Lerdorf wrote:
they are all in sync. For example, Derek Ford's simplexml-related
message
to internals last week(*) worries me somewhat. He passed on what
looks to
be some basic brokeness in the
On Mar 24, 2004, at 12:06 AM, George Schlossnagle wrote:
I don't see where this actually looks up 'element', it seems like it
simply evaluates the existence of node. I committed a fix, but
someone who knows the code better should validate that it is correct.
btw, is there a bug number for this?
The middle case of this dude's example raises a separate concern:
count() does not work for objects - it will always return 1. For
objects that implement the Iterator interface, it seems reasonable for
count() to return a non-trivial answer.
George
--
PHP Internals - PHP Runtime Development
On Wed, 24 Mar 2004, George Schlossnagle wrote:
On Mar 24, 2004, at 12:06 AM, George Schlossnagle wrote:
I don't see where this actually looks up 'element', it seems like it
simply evaluates the existence of node. I committed a fix, but
someone who knows the code better should validate
On Tue, 2004-03-23 at 22:46, Derick Rethans wrote:
No, we decided on no internal functions throwing exceptions (DOM
excluded).
So regardless of context, tidy should be doing docref errors? That takes
away a lot from an internal object standpoint. I thought a much better
approach would be to
63 matches
Mail list logo
