Yes they will be implemented. The only extension which might not follow it
is MySQLi because the author refuses to change it :'(
Andi
At 02:51 AM 4/4/2004 +0200, Sabine Seipel wrote:
Hi,
I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite
for a while ago. But I missed t
Hi,
I follow up the the discussion about studlyCaps in ext/mysqli and ext/sqlite
for a while ago. But I missed the important posts concerning the conclusion
about this topic.
are studlyCaps will be implemented consequently in mysqli and sqlite
extensions?
thanks in advance!
Sabine Seipel
--
+
On Mar 28, 2004, at 4:35 AM, Zeev Suraski wrote:
At 02:41 28/03/2004, Robert Cummings wrote:
Very well put.
+1 for consistency and going all the way with StudlyCaps from me.
I'm in (rare) total agreement with Zeev. :)
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe,
On Sun, 2004-03-28 at 04:35, Zeev Suraski wrote:
> Very well put.
> +1 for consistency and going all the way with StudlyCaps from me.
+1 for consistency, but unless someone is willing to change Georg's
extension for him I don't see this happening.
John
--
-=~=--=~=--=~=--=~=--=~=--=~=--=~=--=~=
On 28 Mar 2004 at 1:20, Lukas Smith wrote:
> Hi,
>
> ok since I have seen a few arguments reoccuring I have decided to
make a
> list of all arguments brought forth. Its in no way a judgement on
any
> argument listed, nor does it list the arguments in any particular
order.
> Therefore, the f
At 02:41 28/03/2004, Robert Cummings wrote:
Don't take this personally please. My voice doesn't count for much on
this list but I do generally read most of the posts. I watched with
interest last year when this thing first became an issue, and now I
think the whole issue has become retarded. It's l
you have two (2) number four's (4) on your list.
> Hi,
>
> ok since I have seen a few arguments reoccuring I have decided to make a
> list of all arguments brought forth. Its in no way a judgement on any
> argument listed, nor does it list the arguments in any particular order.
> Therefore, the fi
On Sat, 2004-03-27 at 19:20, Lukas Smith wrote:
> Hi,
>
> ok since I have seen a few arguments reoccuring I have decided to make a
> list of all arguments brought forth. Its in no way a judgement on any
> argument listed, nor does it list the arguments in any particular order.
> Therefore, the
Hi,
ok since I have seen a few arguments reoccuring I have decided to make a
list of all arguments brought forth. Its in no way a judgement on any
argument listed, nor does it list the arguments in any particular order.
Therefore, the first one to tell me to remove something because the
argume
On 27 Mar 2004 at 10:10, Chuck Hagenbuch wrote:
> Quoting Stefan Walk <[EMAIL PROTECTED]>:
>
> > As far as i can see, that is not neccessary. PEAR naming and
PHP naming
> > would only conflict if a PEAR class extends a PHP class. And i
fail to
> > see cases where that would happen.
>
> That do
Quoting Stefan Walk <[EMAIL PROTECTED]>:
As far as i can see, that is not neccessary. PEAR naming and PHP naming
would only conflict if a PEAR class extends a PHP class. And i fail to
see cases where that would happen.
That doesn't mean it's not going to happen. Try to be a little
forward-thinkin
On Sat, Mar 27, 2004 at 12:11:27PM +0100, Marcus Boerger wrote:
> How do you change all PEAR classes (what was the original reason)?
>
> marcus
As far as i can see, that is not neccessary. PEAR naming and PHP naming
would only conflict if a PEAR class extends a PHP class. And i fail to
see cases
Hello Derick,
Friday, March 26, 2004, 2:43:59 PM, you wrote:
> On Thu, 25 Mar 2004, Andi Gutmans wrote:
>> OK Guys. It's decision time. I suggested to move to studlyCaps and keep
>> consistency with the new PHP 5 changes.
>> If we go with this, I think we should make these changes ASAP and try a
> So, that actually "destroys" the reason to use studlyCaps at all, so why
> not do the right thing and make PHP consistent with itself, ie. use
> under_scores for ALL functions and methods? I'm willing to prepare a
> patch to the source AND documentation to make that happen. And
> because I'm sur
Hello Ilia,
Friday, March 26, 2004, 3:38:35 PM, you wrote:
> On March 26, 2004 09:35 am, you wrote:
>> So one would inherit from/extend a native class and then use studlyCaps and
>> call underscore style methods from parent class. Can you imagine how ugly
>> would this look?
> It may look ugly,
On Friday 26 March 2004 16:54, Andi Gutmans wrote:
> At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote:
> >On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> > > I meant "A bad decision is better than no decision".
> >
> >So this bad decision is to have a standard that everybody is free to
> > i
At 04:50 PM 3/26/2004 +0100, Edin Kadribasic wrote:
On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> I meant "A bad decision is better than no decision".
So this bad decision is to have a standard that everybody is free to ignore?
It means that we change whatever extensions aren't studlyCaps to
On Friday 26 March 2004 16:43, Andi Gutmans wrote:
> I meant "A bad decision is better than no decision".
So this bad decision is to have a standard that everybody is free to ignore?
Edin
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I meant "A bad decision is better than no decision".
Date: Fri, 26 Mar 2004 17:32:13 +0200
To: "Wez Furlong" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>
From: Andi Gutmans <[EMAIL PROTECTED]>
Subject: Re: [PHP-DEV] studlyCaps conclusion
I pretty much agree wit
On Mar 26, 2004, at 10:30 AM, Stefan Walk wrote:
On Fri, Mar 26, 2004 at 07:05:15AM -0800, Rasmus Lerdorf wrote:
On Fri, 26 Mar 2004, Stefan Walk wrote:
Oh, and the strpos/str_repeat inconsistency should be 'fixed' too,
maybe
make strpos an alias to str_pos or alike...
So you are saying strlen()
I pretty much agree with Wez. A bad decision is worse than no decision :)
The way I see it, studlyCaps has been in the CODING_STANDARDS *and*
precisely because people and PEAR use them for method names we should go
with studlyCaps. It would suck to have user-land and internal methods look
differ
On Fri, Mar 26, 2004 at 07:05:15AM -0800, Rasmus Lerdorf wrote:
> On Fri, 26 Mar 2004, Stefan Walk wrote:
> > Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe
> > make strpos an alias to str_pos or alike...
>
> So you are saying strlen() should be str_len() as well? If I e
On Fri, 26 Mar 2004, Stefan Walk wrote:
> Oh, and the strpos/str_repeat inconsistency should be 'fixed' too, maybe
> make strpos an alias to str_pos or alike...
So you are saying strlen() should be str_len() as well? If I ever see a
patch to change that I'll hunt the person down and make them sw
Lets create an engine level option, lets calls it "coding_convention".
The default is "studlyCaps".
Consider the following code:
$foo->fooBarBaz();
When coding_convention=studlyCaps, the engine will resolve the method
thus (psuedo code):
if (!method_exists($obj, $methodname)) {
$tmp_method
On Fri, Mar 26, 2004 at 09:53:28AM -0500, George Schlossnagle wrote:
> As Edin and Lukas have both pointed out, one of the major precepts of
> OO programming is that you can (and often do) overload methods in your
> parent. Adopting two different styles really doesn't work if you ever
> want to
On Mar 26, 2004, at 9:38 AM, Ilia Alshanetsky wrote:
On March 26, 2004 09:35 am, you wrote:
So one would inherit from/extend a native class and then use
studlyCaps and
call underscore style methods from parent class. Can you imagine how
ugly
would this look?
It may look ugly, but without a doubt
On March 26, 2004 09:35 am, you wrote:
> So one would inherit from/extend a native class and then use studlyCaps and
> call underscore style methods from parent class. Can you imagine how ugly
> would this look?
It may look ugly, but without a doubt it would be very clear which code is
'user' and
Edin Kadribasic wrote:
On Friday 26 March 2004 15:27, Ilia Alshanetsky wrote:
Not entirely true, since PHP5 has quite a bit of native OO code, it would
prevent people from easily making a distinction between native and user
created classes/interfaces. It is by no means a deciding problem, but ye
On Friday 26 March 2004 15:27, Ilia Alshanetsky wrote:
> Not entirely true, since PHP5 has quite a bit of native OO code, it would
> prevent people from easily making a distinction between native and user
> created classes/interfaces. It is by no means a deciding problem, but yet
> another reason
On March 26, 2004 09:23 am, George Schlossnagle wrote:
> The StudlyCaps standard only applies inside OO code, so I see this as
> much less of an issue (certainly no worries of conflicts).
Not entirely true, since PHP5 has quite a bit of native OO code, it would
prevent people from easily making a
On Mar 26, 2004, at 9:16 AM, Ilia Alshanetsky wrote:
I should also mention that majority, if not all of the users whom I
spoke to
at the Montreal conference seem to prefer to have PHP stick to a single
naming convention that they are familiar with rather then use 2
distinct
naming conventions. T
I should also mention that majority, if not all of the users whom I spoke to
at the Montreal conference seem to prefer to have PHP stick to a single
naming convention that they are familiar with rather then use 2 distinct
naming conventions. They were even able to raise some valid points we had
Quoting Derick Rethans <[EMAIL PROTECTED]>:
> On Thu, 25 Mar 2004, Andi Gutmans wrote:
>
> > OK Guys. It's decision time. I suggested to move to studlyCaps and keep
> > consistency with the new PHP 5 changes.
> > If we go with this, I think we should make these changes ASAP and try and
> > aim fo
On Thu, 25 Mar 2004, Andi Gutmans wrote:
> OK Guys. It's decision time. I suggested to move to studlyCaps and keep
> consistency with the new PHP 5 changes.
> If we go with this, I think we should make these changes ASAP and try and
> aim for RC2 within two weeks.
Isn't the largest concern consis
At 09:14 AM 3/25/2004 -0600, John Coggeshall wrote:
On Thu, 25 Mar 2004, Andi Gutmans wrote:
> Marcus has already stepped up and showed his willingness to make many of
> the needed changes.
Actually, iirc Marcus reverted that change.
yep because he wanted to wait until we reach a conclusion.
On Mar 25, 2004, at 9:29 AM, Andi Gutmans wrote:
OK Guys. It's decision time. I suggested to move to studlyCaps and
keep consistency with the new PHP 5 changes.
If we go with this, I think we should make these changes ASAP and try
and aim for RC2 within two weeks.
Now I understand it's kind of h
OK Guys. It's decision time. I suggested to move to studlyCaps and keep
consistency with the new PHP 5 changes.
If we go with this, I think we should make these changes ASAP and try and
aim for RC2 within two weeks.
Now I understand it's kind of hard to force extension authors to change
their ow
Nuno Lopes wrote:
>
> I really hate the Studlycaps convention. I prefer the old dash.
Decision was made.
> Why not use this only for new extensions? Do you know the pain to update
> all the docs??...
mysqli, tidy and sqlite are _new_ extensions. At least from the perspective
of PHP's user.
>
>
Marcus Boerger wrote:
> For me one thing counts consistency.
Same here.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
PHP Internals - PHP Runtime Development Mailin
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
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
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 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?
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 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 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, 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, 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, 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 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
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).
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
> >
"George Schlossnagle" <[EMAIL PROTECTED]>; "Edin
Kadribasic" <[EMAIL PROTECTED]>; "Marcus Boerger" <[EMAIL PROTECTED]>; "PHP
Internals" <[EMAIL PROTECTED]>
Sent: Wednesday, March 24, 2004 9:30 AM
Subject: Re: [PHP-DEV] Studlycaps and MySQ
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
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: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, 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
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
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
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
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
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
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
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
>
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
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
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
> 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
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
--- 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
>
> 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, 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
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 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
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
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 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
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
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
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
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
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
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
> 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
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
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 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
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 consistency (and I thing we should) sqlite oo
iterface shou
Hello dv,
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)
Monday, March 22, 2004, 11:57:25 PM, you wrote:
> and SQLite?
>> On Monday 22 March 2004 23:17, Marcus Boerger wrote:
>>> > Hmm, nobod
and SQLite?
> On Monday 22 March 2004 23:17, Marcus Boerger wrote:
>> > Hmm, nobody told me to change it - now it's too late. Maybe we should
>> > change it in PHP6.
>>
>> Obviously nobody was interested in mysqli OO. Since we are still in pre
>> release we can still change something. So it is up
On Monday 22 March 2004 23:17, Marcus Boerger wrote:
> > Hmm, nobody told me to change it - now it's too late. Maybe we should
> > change it in PHP6.
>
> Obviously nobody was interested in mysqli OO. Since we are still in pre
> release we can still change something. So it is up to you to decide. Th
Hello Georg,
Monday, March 22, 2004, 10:44:09 PM, you wrote:
> Hi!
>> Not to start a big flame war here, but if the argument at the end of the
>> day was won for the "Let's use studlyCaps for all OO stuff internal in
>> PHP", shouldn't ext/mysqli conform to that? I changed tidy a while ago,
>> a
Hi!
> Not to start a big flame war here, but if the argument at the end of the
> day was won for the "Let's use studlyCaps for all OO stuff internal in
> PHP", shouldn't ext/mysqli conform to that? I changed tidy a while ago,
> and was surprised to see MySQLi has not...
Hmm, nobody told me to cha
Yes it should. But I don't know if it's possible to change it at this point
(after the RC). It's probably worth it.
Andi
At 01:11 AM 3/22/2004 -0500, John Coggeshall wrote:
Not to start a big flame war here, but if the argument at the end of the
day was won for the "Let's use studlyCaps for all
Not to start a big flame war here, but if the argument at the end of the
day was won for the "Let's use studlyCaps for all OO stuff internal in
PHP", shouldn't ext/mysqli conform to that? I changed tidy a while ago,
and was surprised to see MySQLi has not...
John
--
-=~=--=~=--=~=--=~=--=~=--=~=
Cristiano Duarte wrote:
>IMHO we shouldn't have exceptions. If the DOM
extension (and many others)
>must use StudlyCaps (because of W3C specifications),
all OO-based extension or
>code should use too.
>We can live with a CS for procedural and other CS for
OOP.
>Cristiano Duarte
Yes,
Look at what
On Dec 6, 2003, at 12:40 PM, Stefan Walk wrote:
On Sat, Dec 06, 2003 at 11:45:12AM -0500, George Schlossnagle wrote:
Why should methods differ from functions in naming? That in itself is
inconsistency...
I'm in favour of naming with underscores, simply because that was the
PHP way until now and it
I'm using double-underscores "__" to make autoloading of "fake packages" possible.
An example with StudlyCaps:
org__phporb__compiler__IdlCompiler
With underscores:
org__phporb__compiler__idl_compiler
I guess the first is better but I can live with the second.
IMHO we shouldn't have exceptions. I
On Sat, Dec 06, 2003 at 11:45:12AM -0500, George Schlossnagle wrote:
> >Why should methods differ from functions in naming? That in itself is
> >inconsistency...
> >
> >I'm in favour of naming with underscores, simply because that was the
> >PHP way until now and it helps readability a lot.
>
> Th
On Dec 6, 2003, at 11:58 AM, Andrey Hristov wrote:
It's hard but not impossible to extend internal classes. The
workaround is to write thin wrappers with the studlyCaps convention
which only just call the methods in their parents like
INTERNAL_FUNCTION_PARAM_PASSTHRU. After then comes the real c
1 - 100 of 153 matches
Mail list logo
