On Sat, 5 Apr 2003, Sebastian Bergmann wrote:
> Rasmus Lerdorf wrote:
> > Along the same lines, why do you care if you can call a static method
> > in a class without declaring it static?
>
> A warning would be nice. After all declaring a static method
> explicitly static using the appropriat
Rasmus Lerdorf wrote:
> Along the same lines, why do you care if you can call a static method
> in a class without declaring it static?
A warning would be nice. After all declaring a static method
explicitly static using the appropriate keyword improves performance (a
bit) because $this does
On Fri, 4 Apr 2003, Per Lundberg wrote:
> On Fri, 2003-04-04 at 19:06, J Smith wrote:
> > It's been said before, but PHP isn't C++ or Java, so why would they have to
> > be compatible?
>
> Because it will make it easier for C++ or Java programmers to find PHP a
> pleasant experience.
Only the peo
..
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> On Thu, 2003-04-03 at 20:12, Chris Vandomelen wrote:
> > I've taken the time to make a bunch of changes to ext/xml over the past
> > few days:
>
> I haven't tested it, but after a quick glance it looks ok. Go ahead and
> commit it to HEAD - we have a very long QA cycle ahead anyhow :)
I don't h
On Fri, 4 Apr 2003 20:30:23 -0500
"John Coggeshall" <[EMAIL PROTECTED]> wrote:
>
> I haven't done a comparison, but imagecopyrotated() isn't something I
> made -- I ported it from the latest version of the GD library. If you
> think you could make a better imagecopyrotated() I don't have a
> prob
I haven't done a comparison, but imagecopyrotated() isn't something I
made -- I ported it from the latest version of the GD library. If you
think you could make a better imagecopyrotated() I don't have a problem
with it, but I don't really see a great deal of need.
John
-~=~--~=~--~=~--~=~--~=~
On Fri, 4 Apr 2003 13:11:04 -0500
"John Coggeshall" <[EMAIL PROTECTED]> wrote:
>
> I've ported three GD functions from the 2.0.12 version of GD into the
> bundled version: imagesetclip(), imagegetclip(), and
> imagecopyrotated()... I may go through and port more but I wanted to
> see the response
On April 4, 2003 01:11 pm, John Coggeshall wrote:
> I've ported three GD functions from the 2.0.12 version of GD into the
> bundled version: imagesetclip(), imagegetclip(), and
> imagecopyrotated()... I may go through and port more but I wanted to see
> the response to this before I wasted more tim
On Fri, 2003-04-04 at 19:35, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 12:42, Martin Jansen wrote:
> > On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote:
> > > On Fri, 2003-04-04 at 12:26, Martin Jansen wrote:
> > > > "In PECL all code has to follow the PHP coding standards."
> > > > (http://
Something like
astyle --style=kr --pad=all (reformat in Kernighan and Ritchie style and pad
all operators and parens with spaces)
might be sufficient. It might not catch if(foo)bar, but it'll go a long way
to reducing the number of ws and superficial style fixes that need to be
done.
Joseph
>
On Fri, 4 Apr 2003 12:11:16 -0500, Joseph Tate wrote:
> How about documenting an astyle (insert stylizing app of choice here) line
> in CODING_STANDARDS that people can run on their code to make it conform to
> said standards.
What astyle would you suggest?
--
Tom Sommer, Denmark
www.tsn.dk - w
> The difference between 'pushing' and 'encouraging' is tought in
> management school. The semantical difference is NULL.
Derick, you need to realize that you lack authority. Someone
without authority cannot push anything what so ever.
Or to put it differently:
A bully pushes.
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> > I'm not setting any rules, I'm just trying to push ways of effective
> > collaboration due to the adoption of the same standards for everbody.
>
> You are in no position to push anything.
>
> Try 'encouraging' or 'convincing' the next time.
I've ported three GD functions from the 2.0.12 version of GD into the
bundled version: imagesetclip(), imagegetclip(), and
imagecopyrotated()... I may go through and port more but I wanted to see
the response to this before I wasted more time...
You can find all you need at
http://www.coggeshall
> Also developing PHP extensions is much different than developing PHP.
> In PHP extensions the code itself is much more encapsulated, in PECL
> individual package development is encapsulated. As long as the code
> follows the php naming conventions (for exported functions), it can
> interact nic
On Fri, 2003-04-04 at 12:42, Martin Jansen wrote:
> On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote:
> > On Fri, 2003-04-04 at 12:26, Martin Jansen wrote:
> > > "In PECL all code has to follow the PHP coding standards."
> > > (http://pear.php.net/manual/en/developers.meaning.php)
> > >
> >
> >
> I'm not setting any rules, I'm just trying to push ways of effective
> collaboration due to the adoption of the same standards for everbody.
You are in no position to push anything.
Try 'encouraging' or 'convincing' the next time.
- Sascha
--
PHP Internals - PHP Runtime Developme
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> Derick, your attempts at setting rules are misguided.
I'm not setting any rules, I'm just trying to push ways of effective
collaboration due to the adoption of the same standards for everbody.
Derick
--
"
On Fri, 2003-04-04 at 19:15, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 12:26, Martin Jansen wrote:
> > "In PECL all code has to follow the PHP coding standards."
> > (http://pear.php.net/manual/en/developers.meaning.php)
> >
>
> Then the manual is wrong.
Oh, come on: You should have come
On Fri, 2003-04-04 at 12:26, Martin Jansen wrote:
> On Fri, 2003-04-04 at 18:26, Sterling Hughes wrote:
> > No, in PEAR. In PECL your code can look however it likes, at least
> > that's my understanding.
>
> The manual states it differently:
>
> "In PECL all code has to follow the PHP coding sta
Once you start down that route, where will it end? When PHP's object model
is 100% compatible with Java and C++ (which is obviously impossible given
the differences between the two)? Or perhaps it should be made compatible
with Ruby or SmallTalk, so experienced Ruby and SmallTalk programmers will
On Fri, 2003-04-04 at 18:26, Sterling Hughes wrote:
> No, in PEAR. In PECL your code can look however it likes, at least
> that's my understanding.
The manual states it differently:
"In PECL all code has to follow the PHP coding standards."
(http://pear.php.net/manual/en/developers.meaning.php)
On Fri, 2003-04-04 at 19:06, J Smith wrote:
> It's been said before, but PHP isn't C++ or Java, so why would they have to
> be compatible?
Because it will make it easier for C++ or Java programmers to find PHP a
pleasant experience.
I think much of the discussion of where PHP should go is a bit
Derick, your attempts at setting rules are misguided.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Fri, 4 Apr 2003, Per Lundberg wrote:
> On Fri, 2003-04-04 at 18:07, Andrei Zmievski wrote:
> > On Fri, 04 Apr 2003, Derick Rethans wrote:
> > > > Well its a BC nightmare, and I don't really see any big advantage.
> > > Agreed, breaking BC for this sounds like a bad idea to me.
> > sometimes I
On Fri, 4 Apr 2003, Andrei Zmievski wrote:
> On Fri, 04 Apr 2003, Derick Rethans wrote:
> > > Well its a BC nightmare, and I don't really see any big advantage.
> >
> > Agreed, breaking BC for this sounds like a bad idea to me.
>
> sometimes I just hate BC..
heh, me too :)
Derick
--
On Fri, 4 Apr 2003, Sascha Schumann wrote:
> I barked at Derick for trying to police me with his docref
> pet stuff.
1. It's not my stuff
2. I'm not particulairy fond of it either, but that doesn't mean I don't
use it in my code for the PHP project.You may object or not, but if
it
How about documenting an astyle (insert stylizing app of choice here) line
in CODING_STANDARDS that people can run on their code to make it conform to
said standards. Then people can just run $astyle on their file before they
commit it.
Joseph
> -Original Message-
> From: Sterling Hughes
Sterling Hughes <[EMAIL PROTECTED]> wrote:
>
> Ahh, well, you should follow the coding standards regardless, or rather
> change them. I've just removed docref and assert bogusness from the
> files, so, in that case, you are no longer in violation. (you should
> throw a party. ;-)
Hmm, I partly a
It's been said before, but PHP isn't C++ or Java, so why would they have to
be compatible?
J
Per Lundberg wrote:
> On Fri, 2003-04-04 at 18:07, Andrei Zmievski wrote:
>> On Fri, 04 Apr 2003, Derick Rethans wrote:
>> > > Well its a BC nightmare, and I don't really see any big advantage.
>> > A
On Fri, 2003-04-04 at 11:54, Sascha Schumann wrote:
> Sterling, you are missing some important points here.
>
> > Geeze Luise, its not that hard, and the coding standards are there for a
> > (good) reason. If you object to some of the standards, discuss that,
>
> If you look at my code,
On Fri, 2003-04-04 at 18:07, Andrei Zmievski wrote:
> On Fri, 04 Apr 2003, Derick Rethans wrote:
> > > Well its a BC nightmare, and I don't really see any big advantage.
> > Agreed, breaking BC for this sounds like a bad idea to me.
> sometimes I just hate BC..
Why only sometimes?
Besides, it i
Sterling, you are missing some important points here.
> Geeze Luise, its not that hard, and the coding standards are there for a
> (good) reason. If you object to some of the standards, discuss that,
If you look at my code, 99% of it follows the coding styles,
because I've adopted th
+1, because your patch is likely to fix the issue #21094.
http://bugs.php.net/21094
Moriyoshi
Andrei Zmievski <[EMAIL PROTECTED]> wrote:
> Any objections to modifying zend_lookup_class() to support fully
> qualified class names? Meaning, if it's passed 'A::B' it will lookup
> class B in namespa
On Fri, 2003-04-04 at 11:45, Lukas Smith wrote:
> > From: Sterling Hughes [mailto:[EMAIL PROTECTED]
> > Sent: Friday, April 04, 2003 6:09 PM
>
> > Geeze Luise, its not that hard, and the coding standards are there for
> a
> > (good) reason. If you object to some of the standards, discuss that,
>
> From: Sterling Hughes [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 04, 2003 6:09 PM
> Geeze Luise, its not that hard, and the coding standards are there for
a
> (good) reason. If you object to some of the standards, discuss that,
> but the source code should follow a unified style: we have a
Howdy,
Due to recent discussions, I have an idea for avoiding the whole mess of
annoying coding standards commits that Jani and Derick constantly make.
Follow the coding standards!
Geeze Luise, its not that hard, and the coding standards are there for a
(good) reason. If you object to some of t
Any objections to modifying zend_lookup_class() to support fully
qualified class names? Meaning, if it's passed 'A::B' it will lookup
class B in namespace A? This change would take a care of several places
in the code where class name can be passed.
-Andrei ht
On Fri, 04 Apr 2003, Derick Rethans wrote:
> > Well its a BC nightmare, and I don't really see any big advantage.
>
> Agreed, breaking BC for this sounds like a bad idea to me.
sometimes I just hate BC..
-Andrei http://www.gravitonic.com/
* Use the source,
Hmm.. I thought I had taken care of that. Thank you for taking care of
it for me.
John
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--
So even renaming the list didn't help? :)
--Jani
On Fri, 4 Apr 2003, Magnus Maatta wrote:
>
>
>On Fri, 4 Apr 2003 09:56:41 +0700
>Jumadi Francisco Simangunsong <[EMAIL PROTECTED]> wrote:
>
>> How to make Socket with PHP
>>
>
>For the zillionth time. This is wrong list. Please
Something wrong?
ext/curl/multi.lo: In function 'zif_curl_multi_info_read':
/usr/src/web/php/php5/ext/curl/multi.c:224: undefined reference to
'zend_list_id_by_pointer'
collect2: ld returned 1 exit status
make: *** [sapi/cli/php] Error 1
--Jani
--
PHP Internals -
Like Sterling already told you, I committed it to HEAD last night.
But you forgot to mention that it requires T1lib 5.0.0..
I changed the t1lib check so that it checks for this T1_StrError()
function instead.
--Jani
On Fri, 4 Apr 2003, John Coggeshall wrote:
>
>
On Thu, 2003-04-03 at 20:12, Chris Vandomelen wrote:
> I've taken the time to make a bunch of changes to ext/xml over the past
> few days:
I haven't tested it, but after a quick glance it looks ok. Go ahead and
commit it to HEAD - we have a very long QA cycle ahead anyhow :)
-Sterling
--
"Whet
On Fri, 4 Apr 2003, Sterling Hughes wrote:
> On Fri, 2003-04-04 at 09:52, Andrei Zmievski wrote:
> > What does everyone think about disallowing non-instance calls to methods
> > which are not declared static? Currently, this works:
> >
> > class A {
> > function B() { return 1; }
> >
On Fri, 2003-04-04 at 10:11, John Coggeshall wrote:
> Does anyone have a problem with me committing the T1Lib/GD patch for
> error reporting?
>
jani already committed it last night.
-Sterling
> -~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
> John Coggeshall
> john at c
On Fri, 2003-04-04 at 09:52, Andrei Zmievski wrote:
> What does everyone think about disallowing non-instance calls to methods
> which are not declared static? Currently, this works:
>
> class A {
> function B() { return 1; }
> }
>
> A::B();
>
> But really, if B was int
Does anyone have a problem with me committing the T1Lib/GD patch for
error reporting?
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at coggeshall dot org http://www.coggeshall.org/
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~
>What does everyone think about disallowing non-instance calls
>to methods which are not declared static? Currently, this works:
I like the idea, but wouldn't that cause some problems with BC?
-~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~--~=~-
John Coggeshall
john at cogges
What does everyone think about disallowing non-instance calls to methods
which are not declared static? Currently, this works:
class A {
function B() { return 1; }
}
A::B();
But really, if B was intended to be used that way, it should have been
declared as stati
Sascha Schumann wrote:
> Well, indent(1) will probably achieve the same result with
> the right options..
Then why not agree on a correct set of indent options, apply them to
the whole tree at once and maybe integrate indent into our CVS system
so that it is automatically applied after a che
On Thu, 2003-04-03 at 20:42, Andrei Zmievski wrote:
> Today I ran into a problem because I needed to register an internal
> class that had some protected methods. Currently, the only way to do it
> is by doing a zend_hash_find() on ce->function_table after registration
> and updating fn_flags field
53 matches
Mail list logo
