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 consisten
What about the change in order of some function names? Are you sure you
want to keep it this way?
At 08:03 AM 3/23/2004 +, Marcus Boerger wrote:
helly Tue Mar 23 03:03:12 2004 EDT
Modified files:
/php-srcNEWS
/php-src/ext/sqlite sqlite.c
/php-src/ext/sqlite/tests
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 testcas
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, germa
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
- c
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 author
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, 2
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 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
to the point that they won't work (it's a nic
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 fi
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 cert
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 no
On March 23, 2004 10:44 am, Edin Kadribasic wrote:
> 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 fist official
> release?
Had this been a change of functionality that existed for a short period of
time I woul
Edin Kadribasic wrote:
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 fist official
release?
I agree. Having two names and introducing deprecated names now is pure
bloat and maintenance hell. Let people fix all t
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
pref
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 reall
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?
> >
> >
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
>
> 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 oth
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 th
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 w
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>>
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
s
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 attacki
> 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
> Studly
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 stand
Hello Andi,
Monday, March 22, 2004, 11:24:03 AM, you wrote:
> What would you expect? That if a new style constructor is defined we always
> use that and allow old-style as regular method?
exactly - and we had that before RC1-final.
marcus
--
PHP Internals - PHP Runtime Development Mailing Lis
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
undersco
On Mar 23, 2004, at 3:05 PM, John Coggeshall 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.
My book is on the shelves and things got changed under me (exceptions
forced to derive
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 - a
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 tha
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 pe
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 suc
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 d
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 announcin
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: http:/
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
> s
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
> >> > igno
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
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
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 nobo
I'm in the "change it to be consistent" boat
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Georg Richter" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; "George Schlossnagle" <[EMAIL PROTECTED]>; "Edin
Kadribasic" <[EMAIL PROTEC
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
> >
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 in
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
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
cons
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 t
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 oth
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:
> Sterling. We did come to a decision on this mailing list. In case you were
> asleep, well read the archives.
I've been looking for that, but couldn't find it at all. (It's
mentioned, but nobody agreed on most of it).
> The fact is that consistency is im
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.
>
> (*) http://news.p
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 extensi
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 M
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 va
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 ha
71 matches
Mail list logo
