Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

Thanks guys for your feedback. With regard to PEAR, I've had to patch PEAR::DB::mysql to solve another problem I've had with the prepared_queries field growing steadily. I'm sure this is also a problem with the either DB subclasses. I'll post my patch to pear-dev as I don't have a CVS account yet.

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

D'oh - read too little, too fast. :) On Tue, Mar 25, 2003 at 05:55:42PM -0800, Zeev Suraski wrote: > I believe he meant the query id's that the engine uses, and not the auto > increment id's. Wez's response was accurate, we'll overflow at some > point. This is basically because PHP was designe

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

I believe he meant the query id's that the engine uses, and not the auto increment id's. Wez's response was accurate, we'll overflow at some point. This is basically because PHP was designed with short requests in mind. We could probably fix it relatively easily for ZE2. Zeev At 13:15 25/03

Re: [PHP-DEV] Is this a bug?

--- Tony Bibbs <[EMAIL PROTECTED]> wrote: > Are there instances you all can think of where doing a header('location: > $url'); causes a loss of all session data? This is most likely not a bug. You can (hopefully) find more people to help with this type of question on [EMAIL PROTECTED] Good luck.

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query and possible integer overflow?

On Tue, Mar 25, 2003 at 01:50:17PM +, Matt Flaherty wrote: > Hi, > > I have a question for the authors of the mysql extension. I'm sure you > gentlemen are very busy, but I'd appreciate your insight if you can > spare a moment. I'm developing a stand-alone php application running in > an infin

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

Thanks Wez, If all that happens is the query will fail, I can live with that. It's a simple SELECT query called over and over again. If the integer wraps around negative, I'm guessing that would probably have undesirable effects. If not, then I can let it run forever. What I don't want is somethin

Re: [PHP-DEV] Question for Zeev, Zak or Georg - mysql_query andpossible integer overflow?

Hi Matt, Yes, there is a risk of overflow. >From my understanding, the id is signed, so you will hit overflow at 2G rather than 4G resources. This applies to any/all PHP/ZE resources. I'm not sure what happens when it overflows; it seems like the query would fail. You could design your applicati

Re: [PHP-DEV] [PATCH] OCI8 link failure (Tru64/AIX) (#22324)

Attached is patch for ext/oci8/config.m4, please try it out. --Jani On Tue, 11 Mar 2003, Michael Mauch wrote: >Jani Taskinen <[EMAIL PROTECTED]> wrote: >> >>I still don't think we should be linking with libocijdbc8 in any case. >>Can you ask some Oracle support why their libs

Re: [PHP-DEV] ze2 segfault #2

Nevermind, I found the bug, and I have a fix that I'm testing right now. -Sterling On Fri, 2003-03-21 at 16:53, Sterling Hughes wrote: > When running the following example through pres2 (apache 1.3.27), I get > a segfault.. Sample pres2 file. > > > Interfaces Suck > They really do > > > > i

Re: [PHP-DEV] segfault with ze2/php5-cvs

On Fri, 2003-03-21 at 15:12, Joey Smith wrote: > Very nice. > > What about: > >class person { > var $name; > } > > $start = new person; > $start->name = 'Eve'; > $new = $start->__clone(); > ?> > > Does it come back with 'Call to a member function on

Re: [PHP-DEV] segfault with ze2/php5-cvs

Very nice. What about: name = 'Eve'; $new = $start->__clone(); ?> Does it come back with 'Call to a member function on a non-object'? On Fri, Mar 21, 2003 at 02:47:06PM -0500, Sterling Hughes wrote: > class sheep { > var $name; > } > > $start = new sheep; > $start->name = "Dolly"

Re: [PHP-DEV] Language Auto Detection / www.php.net

On Wed, 2003-03-12 at 11:31, James Cox wrote: > Gabor Hojtsy <[EMAIL PROTECTED]> wrote: > > > > is there any chance that we can revert this annoying feature? > > > The translated documentation is always behind and partly lacks > > > important information from the english version. I want to read >

Re: [PHP-DEV] Pb : access control

t;;) and in the inheritance context ($test->show();) Hope that will help debug PHP5 Fabrice Le Coz [EMAIL PROTECTED] - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Fabrice Le Coz" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]&

Re: [PHP-DEV] 4.3.2RC1: patch to compile with libgd < 2

nope. Was introduced by this late fix: http://cvs.php.net/diff.php/php4/ext/gd/gdttf.c?login=2&r1=1.17&r2=1.18&ty=h and merged into 4.3.2RC1. Jani Taskinen wrote: Please try the latest STABLE cvs snapshot from http://snaps.php.net as this seems to be fixed already. -- -- Roberto Bianca

Re: [PHP-DEV] 4.3.2RC1: patch to compile with libgd < 2

Please try the latest STABLE cvs snapshot from http://snaps.php.net as this seems to be fixed already. --Jani On Sat, 15 Mar 2003, Roberto Biancardi wrote: >--- ext/gd/gdttf.c.orig Sat Mar 15 22:38:28 2003 >+++ ext/gd/gdttf.c Sat Mar 15 22:42:42 2003 >@@ -744,9 +74

Re: [PHP-DEV] Pb : access control

Can you cut down the script to like 10 lines and say what your result is and what you'd expect? At 05:37 PM 3/17/2003 +0100, Fabrice Le Coz wrote: Hi, I'm playing with PHP5 and have some trouble wtith access control, here's the code I run with last php5 from snaps.php.net under windows XP :

Re: [PHP-DEV] RPC Extension

Other issues: 1) Passing This to callbacks Also I think we should pass getThis() to the handlers too rpc_call(zval *this, rpc_string, void *, zval *, int, zval *** TSRMLS_DC); 2) Return object types I see that the rpc layer is actually trying to register a new zend class for every new Com("somecla

Re: [PHP-DEV] 64bit PHP on solaris

For my own education, is there a reason they were passed as void* to begin with? On Fri, 2003-03-14 at 23:43, James Devenish wrote: > In message <[EMAIL PROTECTED]> > on Fri, Mar 14, 2003 at 05:22:11PM +, Wez Furlong wrote: > > Please coordinate with me on streams issues; if some 64bit oses

Re: [PHP-DEV] 64bit PHP on solaris

> Even so, I don't know what would be hard for anyone to understand about > my patches (and no-one has asked me in the past). If you think there > simply too many of them, most of them are probably whitespace > disagreements between what you committed and what the PHP style appears > to be. The bas

RE: [PHP-DEV] Possible problem in the parser

At 13:01 14.03.2003, Ford, Mike [LSS] wrote: > >Just to make this completely clear, in left-associative PHP > > > >b = a==1? 4:a==2? 5:6; > > > >is equivalent to > > > >b = (a==1? 4:a==2)? 5:6; > > > NO it is not equal. Either '==' has higher precedence OR '?:' has. > See one

Re: [PHP-DEV] 64bit PHP on solaris

On Sat, 15 Mar 2003, James Devenish wrote: > Regardless of what you personally understand (and what I personally > understand), my point would be that the problems are simply unfixed > by *anyone*. This is the first time that anyone has brought this issue to my attention. > Index: main/streams.c

Re: [PHP-DEV] 64bit PHP on solaris

In message <[EMAIL PROTECTED]> on Fri, Mar 14, 2003 at 05:22:11PM +, Wez Furlong wrote: > Please coordinate with me on streams issues; if some 64bit oses > declare descriptors as longs rather than ints, then we could have a > bigger job on our hands (similar to the mess with socket types under

Re: [PHP-DEV] 64bit PHP on solaris

> > Which part of "please coordinate with me on streams issues" didn't you > get? ;-) > > If there are long vs int issues in streams, please let me know where > they are and I will fix it. > > Thanks :) Forgive me if I am a bit dense tonight :-) My 15 yr old son is having a lan party in the baseme

Re: [PHP-DEV] 64bit PHP on solaris

On Fri, 14 Mar 2003, David Hill wrote: > > Please coordinate with me on streams issues; if some 64bit oses declare > > descriptors as longs rather than ints, then we could have a bigger job > > on our hands (similar to the mess with socket types under win32). > > Tru64 & HP-UX (and I would guess S

Re: [PHP-DEV] 64bit PHP on solaris

> Please coordinate with me on streams issues; if some 64bit oses declare > descriptors as longs rather than ints, then we could have a bigger job > on our hands (similar to the mess with socket types under win32). Tru64 & HP-UX (and I would guess Solaris and the rest) - the descriptor is an in

Re: [PHP-DEV] 64bit PHP on solaris

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a > large patch and probably no one got to check it all out). Then, I > reposted them (and sent then directly to you, Dave!) a few days ago. And I got all but the three files merged that are probably causing his problem too -

Re: [PHP-DEV] 64bit PHP on solaris

Please coordinate with me on streams issues; if some 64bit oses declare descriptors as longs rather than ints, then we could have a bigger job on our hands (similar to the mess with socket types under win32). --Wez. On Fri, 14 Mar 2003, David Hill wrote: > > CRIPES, people! I posted patches in N

Re: [PHP-DEV] 64bit PHP on solaris

> CRIPES, people! I posted patches in November 2002 (admittedly, it was a > large patch and probably no one got to check it all out). Then, I > reposted them (and sent then directly to you, Dave!) a few days ago. And I got all but the three files merged that are probably causing his problem too -

RE: [PHP-DEV] Possible problem in the parser

> -Original Message- > From: Andi Gutmans [mailto:[EMAIL PROTECTED] > Sent: 14 March 2003 14:50 > > You are right that it doesn't behave the same as C. However, > personally > although it might have been better for it to work like C I > don't think it's > a good idea to change it now.

RE: [PHP-DEV] Possible problem in the parser

On Fri, 14 Mar 2003, Andi Gutmans wrote: >You are right that it doesn't behave the same as C. However, personally >although it might have been better for it to work like C I don't think it's >a good idea to change it now. First of all it would break backwards >compatibility in a way which would

RE: [PHP-DEV] Possible problem in the parser

rom: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 13 March 2003 19:33 > To: Ford, Mike [LSS] > Cc: 'Andrey Hristov'; [EMAIL PROTECTED] > Subject: RE: [PHP-DEV] Possible problem in the parser > > > At 14:58 13.03.2003, Ford, Mike [LSS] wrote: > >

RE: [PHP-DEV] Possible problem in the parser

> -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: 13 March 2003 19:33 > To: Ford, Mike [LSS] > Cc: 'Andrey Hristov'; [EMAIL PROTECTED] > Subject: RE: [PHP-DEV] Possible problem in the parser > > > At 14:58 13.03.2003,

RE: [PHP-DEV] Re: Segmentation violation

what is your platform ? > -Original Message- > From: Matt [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 12, 2003 6:03 PM > To: [EMAIL PROTECTED] > Subject: [PHP-DEV] Re: Segmentation violation > > > J, I will post an issue, but as far as I can tell the error is very > intermittent

Re: [PHP-DEV] 64bit PHP on solaris

In message <[EMAIL PROTECTED]> on Thu, Mar 13, 2003 at 02:05:45PM -0500, David Hill wrote: > > > first file_get_contents & readfile both core dump with bus errors > b/c > > > the file descriptors are typed as int's when they should be longs > > > (steams.c lines 1020/1156) > > The lines don't matc

RE: [PHP-DEV] Possible problem in the parser

At 14:58 13.03.2003, Ford, Mike [LSS] wrote: Just to make this completely clear, in left-associative PHP b = a==1? 4:a==2? 5:6; is equivalent to b = (a==1? 4:a==2)? 5:6; NO it is not equal. Either '==' has higher precedence OR '?:' has. See one of my previous mails where i

Re: [PHP-DEV] 64bit PHP on solaris

Chris, some of these changes went in a few days ago, so you want to: cvs co -r PHP_4_3 php4 or grab the release candidate. > > first file_get_contents & readfile both core dump with bus errors b/c > > the file descriptors are typed as int's when they should be longs > > (steams.c line

Re: [PHP-DEV] 64bit PHP on solaris

Of the PHP_4_3 branch? Could you open a bug report for each of these three issues at bugs.php.net? --Wez. On Thu, 13 Mar 2003, Chris Field wrote: > I am working off a checkout from about three days ago... > > On Thu, 2003-03-13 at 11:21, Wez Furlong wrote: > > Make sure that you are using the l

Re: [PHP-DEV] 64bit PHP on solaris

I am working off a checkout from about three days ago... On Thu, 2003-03-13 at 11:21, Wez Furlong wrote: > Make sure that you are using the latest stable snapshot from > http://snaps.php.net; a number of 64bit issues have already been addressed. > > --Wez. > > On Thu, 13 Mar 2003, Chris Field

Re: [PHP-DEV] 64bit PHP on solaris

Make sure that you are using the latest stable snapshot from http://snaps.php.net; a number of 64bit issues have already been addressed. --Wez. On Thu, 13 Mar 2003, Chris Field wrote: > We have been attempting to run php on a brand new sun v880, and have had > a number of problems. > > first fil

Re: [PHP-DEV] CVS Account Request: jorton

On Thu, Mar 13, 2003 at 04:18:51PM +0100, Sascha Schumann wrote: > On Thu, 13 Mar 2003, Joe Orton wrote: > > > Commit of autoconf code cleanups to php4 (4_3 branch) needed > > for systems which have system libraries in /usr/lib64 rather > > than /usr/lib. > > Please post patches. I have done

Re: [PHP-DEV] CVS Account Request: jorton

On Thu, 13 Mar 2003, Joe Orton wrote: > Commit of autoconf code cleanups to php4 (4_3 branch) needed > for systems which have system libraries in /usr/lib64 rather > than /usr/lib. Please post patches. - Sascha -- PHP Development Mailing List To unsubscribe, visit

Re: [PHP-DEV] Scope and namespace

At 15:54 13/03/2003, Andrei Zmievski wrote: On Thu, 13 Mar 2003, Zeev Suraski wrote: > Not really, we can't. You can have functions inside a namespace, that > don't have a class entry attached to them. > I guess we could create some hybrid of the namespace and ce, but it would > end up being ugly,

Re: [PHP-DEV] Scope and namespace

On Thu, 13 Mar 2003, Zeev Suraski wrote: > Not really, we can't. You can have functions inside a namespace, that > don't have a class entry attached to them. > I guess we could create some hybrid of the namespace and ce, but it would > end up being ugly, with many more extra checks. Suppose we

RE: [PHP-DEV] Possible problem in the parser

> -Original Message- > From: Andrey Hristov [mailto:[EMAIL PROTECTED] > Sent: 12 March 2003 17:26 > > > On Wed, 12 Mar 2003, Andrey Hristov wrote: > > > > > Few minutes ago I found the following behaviour somehow > wierd for me : > > > > Known bug, the associativity of the ternary op

Re: [PHP-DEV] Scope and namespace

At 23:48 12/03/2003, Andrei Zmievski wrote: Seeing as how we now have only one-level deep namespaces and classes (which is another topic), does it make sense to have both 'scope' and 'ns' fields in zend_op_array structure? I would think they can be merged into one. Not really, we can't. You can ha

Re: [PHP-DEV] Moderate PHP-DEV

Sterling Hughes wrote: In what country can you walk onto the floor of the congress (parliament) without sponsorship? OTOH in which country do you *trust* your parliament? -- Six Offene Systeme GmbH http://www.six.de/ i.A. Hartmut Holzgraefe Email: [EMAIL PROTECTED] Tel.: +49-711-99091-7

Re: [PHP-DEV] Moderate PHP-DEV

Sascha Schumann wrote: The list could be renamed so that it is less confusing for newbie PHP developers. it is already advertised as "Internals list" on http://www.php.net/mailing-lists.php, so maybe we should cange it to php-internal-dev@ or something? or even better [EMAIL PROTECTED] ;)

Re: [PHP-DEV] compiling PHP_4_3

Nevermind, stupid me made stupid mistake Rasmus Lerdorf wrote: Did you actually check out version 4.3? cvs co -r PHP_4_3 php4 Check your CVS/Entries file. You should see the branch name after each file. -Rasmus On Thu, 13 Mar 2003, Corne' Cornelius wrote: Hi, I compiled CLI version of

Re: [PHP-DEV] compiling PHP_4_3

[EMAIL PROTECTED]:~/php4/main$ cvs status main.c === File: main.cStatus: Up-to-date Working revision:1.512.2.16 Repository revision: 1.512.2.16 /repository/php4/main/main.c,v Sticky Tag: PHP_4_3 (bra

Re: [PHP-DEV] compiling PHP_4_3

Yep, it's branch PHP_4_3 and ran a cvs update just before compiling -Corne' Rasmus Lerdorf wrote: Did you actually check out version 4.3? cvs co -r PHP_4_3 php4 Check your CVS/Entries file. You should see the branch name after each file. -Rasmus On Thu, 13 Mar 2003, Corne' Cornelius wrote:

RE: [PHP-DEV] compiling PHP_4_3

Hi Corne, The latest stable works fine for CLI from http://snaps.php.net/ Regards --jm > -Original Message- > From: Corne' Cornelius [mailto:[EMAIL PROTECTED] > Sent: Thursday, March 13, 2003 9:29 AM > To: [EMAIL PROTECTED] > Subject: [PHP-DEV] compiling PHP_4_3 > > > Hi, > > I compil

Re: [PHP-DEV] compiling PHP_4_3

Did you actually check out version 4.3? cvs co -r PHP_4_3 php4 Check your CVS/Entries file. You should see the branch name after each file. -Rasmus On Thu, 13 Mar 2003, Corne' Cornelius wrote: > Hi, > > I compiled CLI version of PHP_4_3 this morning and it gave the following: > > php4/main/

Re: [PHP-DEV] Moderate PHP-DEV

I think, on web page is bad text. User's don't know if is it for PHP developers or "about" _PHP_ developers.. Jan > On Wed, 12 Mar 2003, Jani Taskinen wrote: > > > > > Of about 20 emails today, 6 were posted to wrong mailing > > list. And one of those

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Tom Sommer wrote: > On Wed, 12 Mar 2003 23:44:20 +0200 (EET), Jani Taskinen wrote: > > > 1. Rename the list to php-group > > And the newsgroup? since lots of the spam comes from NNTP directly, I would > think(?) Some does, but not a lot. Derick --

Re: [PHP-DEV] Moderate PHP-DEV

On Thu, 13 Mar 2003, Andi Gutmans wrote: > At 11:01 PM 3/12/2003 +0100, Sascha Schumann wrote: > > > I wouldn't consider 3rd one that drastic. > > > It has worked very well for me, I haven't got any spam > > > to my php.net addy, but people who really wanted to send me > > > email

Re: [PHP-DEV] Moderate PHP-DEV

> > We don't lose anything by giving the first two items some > > time to prove their usefullness. On the other hand, it is > > very likely that we will lose useful input, if we implement > > the third item prematurely. > > I disagree. Anyone here can handle replying because we alr

Re: [PHP-DEV] Moderate PHP-DEV

At 11:01 PM 3/12/2003 +0100, Sascha Schumann wrote: > I wouldn't consider 3rd one that drastic. > It has worked very well for me, I haven't got any spam > to my php.net addy, but people who really wanted to send me > email got through.. Well, maybe I am an exception, but I usual

Re: [PHP-DEV] Need some ZE2 functions exported.

Marcus, i tried to use spl_functions.c and got the same errors. i think that because im building php as shared that those symbols must be exported for my code to work. l0t3k "Marcus Börger" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > At 15:54 12.03.2003, l0t3k wrote: > >im try

Re: [PHP-DEV] Re: [PHP] Re: [PHP-DEV] Is PHP designed (have the capability) to access remote DB?

On Wed, 12 Mar 2003 13:39:36 - (GMT), you wrote: >but your not. Please redirect further rants to [EMAIL PROTECTED] where >they will be able to help. Careful...devnull.com is an actual domain. :-) Although giveashit doesn't seem to exist: 550 5.1.1 [EMAIL PROTECTED] User unknown -- PHP Deve

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

At 21:12 12.03.2003, Shane Caraveo wrote: An interface should not implement an interface, only classes should implement interfaces. 'implement' infers that actual executable code is provided that implements an interface. Again, I haven't followed the interface stuff, and sorry for writting wit

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Sascha Schumann wrote: >> I wouldn't consider 3rd one that drastic. >> It has worked very well for me, I haven't got any spam >> to my php.net addy, but people who really wanted to send me >> email got through.. > >Well, maybe I am an exception, but I usual

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003 23:44:20 +0200 (EET), Jani Taskinen wrote: > 1. Rename the list to php-group And the newsgroup? since lots of the spam comes from NNTP directly, I would think(?) -- Tom Sommer, denmark www.tsn.dk - www.dreamcoder.dk -- PHP Development Mailing List

Re: [PHP-DEV] Moderate PHP-DEV

> I wouldn't consider 3rd one that drastic. > It has worked very well for me, I haven't got any spam > to my php.net addy, but people who really wanted to send me > email got through.. Well, maybe I am an exception, but I usually don't bother to "register" myself anywhere,

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Sascha Schumann wrote: >Jani, > >> 1. Rename the list to php-group > >bad name for obvious reasons. Georg's suggestion of >"internals" sounds ok to me. Or "hackers" from the FreeBSD >community. internals,hackers,whatever, as long as it's not php-dev.

Re: [PHP-DEV] Moderate PHP-DEV

Jani, > 1. Rename the list to php-group bad name for obvious reasons. Georg's suggestion of "internals" sounds ok to me. Or "hackers" from the FreeBSD community. > 2. Separate the list entries in mailing-lists.php [DONE!] > 3. Apply the same system as is in use

Re: [PHP-DEV] Moderate PHP-DEV

After reading all the comments, I came to conclusion that we will do the following compromise: 1. Rename the list to php-group 2. Separate the list entries in mailing-lists.php [DONE!] 3. Apply the same system as is in use for our @php.net addresses for spam-pr

Re: [PHP-DEV] Moderate PHP-DEV

This discussion itself is creating more spam than those emails people send. I agree with Sascha that we shouldn't take drastic measures. We still want to make it easy for people to join the PHP developer's community. I think the most interesting idea so far was Shane's first post response system.

Re: [PHP-DEV] Moderate PHP-DEV

> Aside from renaming the php-dev list, we should remove the 'PHP and Zend > Engine internals lists' from the regular mailing list page, put them in > a 'developers' section (name isn't important) that describes cvs access, > dev email lists, how to build (ie. win32 libraries), etc. As a newbie c

Re: [PHP-DEV] Moderate PHP-DEV

On Wednesday 12 March 2003 17:59, Jani Taskinen wrote: > Of about 20 emails today, 6 were posted to wrong mailing > list. And one of those generated a 5 email thread about not > posting to wrong mailing list. (counting this one :) > > So I suggest we finally make this list MODERATED

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Sascha Schumann wrote: > > Yes, because getting a cvs account is just *s* hard. > > The problem is that you easily lose valuable postings when > you force people to go through some restrictive system. > > I'm especially worried about inter-group communication

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Tom Sommer wrote: > I agree, I think changing the name is the way to go, and to remove it from > the public mailing lists (or put it under another category) > > Don't forget that mailing lists is not the whole problem, many also use > news groups :) > > php.internal > php.c

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003 15:31:56 -0500, John Coggeshall wrote: > In > any case, moderating this list would end up completely alientating > everyone but those who are "significant developers". I agree, I think changing the name is the way to go, and to remove it from the public mailing lists (or put

RE: [PHP-DEV] Moderate PHP-DEV

We'll see who reads this, any responses are welcome. I see a few different issues here: 1) People who want answers for a php-general message post it to the development forum. This is clearly because they do not understand the difference, as I doubt anyone wants to waste their own time posting a

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

At 08:53 AM 3/12/2003 -0500, Andrei Zmievski wrote: I have 2 questions: 1. Do the interface functions have to be explicitly specified as abstract? Nope. It shouldn't be allowed to be abstract because it's abstract by definition. interface Foo { function bar(); } Because this runs fine

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

Marcus Börger wrote: At 20:20 12.03.2003, Andrei Zmievski wrote: On Wed, 12 Mar 2003, Marcus Börger wrote: > This works even though i do not like extends FOO. Why? Both C# and Java (AFAIR) allow interfaces to extend other interfaces. Because of the second part of the answer. It is a little bit

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

At 20:20 12.03.2003, Andrei Zmievski wrote: On Wed, 12 Mar 2003, Marcus Börger wrote: > This works even though i do not like extends FOO. Why? Both C# and Java (AFAIR) allow interfaces to extend other interfaces. Because of the second part of the answer. It is a little bit strange that an interfac

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003 20:14:03 +0100 (CET) Derick Rethans <[EMAIL PROTECTED]> wrote: > Instead of this it might be a better idea to make somebody's first post > moderated, after it has been approved the poster is added to the allow > list, if not he gets back a message like I copy&paste everytime

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

On Wed, 12 Mar 2003, Marcus Börger wrote: > >interface JAZ {} > >interface FOO {} > >interface BAR extends FOO {} > >class foo implements FOO {} > > This works even though i do not like extends FOO. Why? Both C# and Java (AFAIR) allow interfaces to extend other interfaces. > This doesn't - i ho

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Sascha Schumann wrote: > > You lose: > > You lose time for implementing and maintaining this system, > and you lose time for moderating emails. You also reduce the > incentive to contribute. I lose time to reply to them now too and copy and pasting my stuff, I

Re: [PHP-DEV] Moderate PHP-DEV

> You lose: You lose time for implementing and maintaining this system, and you lose time for moderating emails. You also reduce the incentive to contribute. Again, let's take the less intrusive steps first and leave the heavy handed ones as a last resort. - Sascha --

Re: [PHP-DEV] Moderate PHP-DEV

At 20:00 12.03.2003, Weston Houghton wrote: This worries me somewhat. I do not have a CVS account. I do not actively develop and contribute to the PHP sourcecode right now, however my company uses php very very much. I would like to keep up to date on what is happening with the development team

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Shane Caraveo wrote: > But for the sake of writing...here's another idea. > > So how about a first post response system, similar to the subscription > response. That first post would not actually be posted to the email > list, but rather an email would be sent back to the

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

At 19:57 12.03.2003, Shane Caraveo wrote: A class extending an interface seems just weird to me. classes should only extend classes, and implement interfaces. interfaces can extend interfaces. I haven't been following the interfaces stuff (I'm going to have to backtrack and read it all, very

Re: [PHP-DEV] Moderate PHP-DEV

> Yes, because getting a cvs account is just *s* hard. The problem is that you easily lose valuable postings when you force people to go through some restrictive system. I'm especially worried about inter-group communication. E.g. where php-dev is involved in a discussion wit

Re: [PHP-DEV] Moderate PHP-DEV

Shane Caraveo wrote: Then another item that might be considered if it is not already done, allowing posts only from those that have cvs access. A second conditional list of allowed posters can be added that are people who do not have cvs access, but we want to allow to post. Otherwise, the

Re: [PHP-DEV] Moderate PHP-DEV

A secondary followup, as I do work on php extensions, I do think that questions regarding those would fall to this list, but again might not require a cvs account? Just playing Devil's Advocate to some extent here. Wes On Wednesday, March 12, 2003, at 01:45 PM, Sterling Hughes wrote: On Wed,

Re: [PHP-DEV] Moderate PHP-DEV

> This worries me somewhat. I do not have a CVS account. I do not > actively develop and contribute to the PHP sourcecode right now, > however my company uses php very very much. I would like to keep up to > date on what is happening with the development team and figuring out > what directions they

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 2003-03-12 at 14:00, Weston Houghton wrote: > This worries me somewhat. I do not have a CVS account. I do not > actively develop and contribute to the PHP sourcecode right now, > however my company uses php very very much. I would like to keep up to > date on what is happening with the d

Re: [PHP-DEV] Moderate PHP-DEV

>> If the post does not match this criteria, please send it to >> on of the other lists, otherwise respond to this email and your original >> message will go out. > > And they would probably not read it, just read the part how to get the email > to the list. They don't read the comment what purpos

Re: [PHP-DEV] Moderate PHP-DEV

This worries me somewhat. I do not have a CVS account. I do not actively develop and contribute to the PHP sourcecode right now, however my company uses php very very much. I would like to keep up to date on what is happening with the development team and figuring out what directions they are l

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Magnus [ISO-8859-1] M ![ISO-8859-1] gnus X^B wrote: > On Wed, 12 Mar 2003 10:47:27 -0800 > Shane Caraveo <[EMAIL PROTECTED]> wrote: > > > So how about a first post response system, similar to the subscription > > response. That first post would not actually be posted to the

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003 10:47:27 -0800 Shane Caraveo <[EMAIL PROTECTED]> wrote: > So how about a first post response system, similar to the subscription > response. That first post would not actually be posted to the email > list, but rather an email would be sent back to the poster stating the >

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

Andrei Zmievski wrote: On Wed, 12 Mar 2003, Sebastian Bergmann wrote: I have seen extended interfaces quite often in the Java world. IIRC, the following code currently runs without problems and it should stay that way, if it does not harm us in any way: I wasn't talking about interfaces

Re: [PHP-DEV] Moderate PHP-DEV

> So how about a first post response system, similar to the subscription > response. That first post would not actually be posted to the email > list, but rather an email would be sent back to the poster stating the > purpose of the email list, and what kind of materials are expected on > the list

Re: [PHP-DEV] Moderate PHP-DEV

A couple thoughts Aside from renaming the php-dev list, we should remove the 'PHP and Zend Engine internals lists' from the regular mailing list page, put them in a 'developers' section (name isn't important) that describes cvs access, dev email lists, how to build (ie. win32 libraries), e

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phptinterface_doubled.phpt interface_implemented.phpt interface_instantiate.phptinterface_member.phpt interface_method.phpt interface_method_final.phptinterface_method_private.phpt interface_must_be_implemented.phpt

Andrei Zmievski wrote: > "class blah implements " is confusing. That is possible? It shouldn't be ;-) -- Sebastian Bergmann http://sebastian-bergmann.de/ http://phpOpenTracker.de/ Did I help you? Consider a gift: http://wishlist.sebastian-bergmann.de/ -- PHP Developmen

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 12 Mar 2003, Sterling Hughes wrote: > It doesn't. They are free to send the mail to whomever they like, even > put up a website with their ideas. They are not censured, they are > restricted. In what country can you walk onto the floor of the congress > (parliament) without sponsorship?

Re: [PHP-DEV] Moderate PHP-DEV

At 18:50 12.03.2003, Steph wrote: php-dev-team might lose a few.. ...think f..ing hard..read.oh php-dev-team...thinkCOOL, they solve my problem, i'm getting better at it and finally a team member >>COOL<< what ever name we give this list draws attention to newbies as long as it contains the

Re: [PHP-DEV] Moderate PHP-DEV

On Wed, 2003-03-12 at 12:50, Sascha Schumann wrote: > > Let's ask the mysql guys, they did change the name too. (I think that we > > atleast agree that the noise is annoying, right?) > > Not really. Maybe I'm more used to skipping noise. > *exactly* my point btw. We skip noise, skip noise,

Re: [PHP-DEV] Re: [PHP-CVS] cvs: php4 /tests/classes interface_class.phpt interface_doubled.phpt interface_implemented.phpt interface_instantiate.phpt interface_member.phpt interface_method.phpt interface_method_final.phpt interface_method_private.phpt interface_must_be_implemented.phpt

On Wed, 12 Mar 2003, Sebastian Bergmann wrote: > I have seen extended interfaces quite often in the Java world. > > IIRC, the following code currently runs without problems and it should > stay that way, if it does not harm us in any way: > > interface Foo {} > interface Bar ex

  1   2   3   4   5   6   7   8   9   10   >