Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:23710
Return-Path: <helly@php.net>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 28369 invoked by uid 1010); 27 May 2006 08:13:02 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 28354 invoked from network); 27 May 2006 08:13:01 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 27 May 2006 08:13:01 -0000
X-PHP-List-Original-Sender: helly@php.net
X-Host-Fingerprint: 81.169.182.136 ajaxatwork.net Linux 2.4/2.6
Received: from ([81.169.182.136:36875] helo=strato.aixcept.de)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 3F/BD-17316-C0A08744 for <internals@lists.php.net>; Sat, 27 May 2006 04:13:00 -0400
Received: from baumbart.mbo (dslb-084-063-047-180.pools.arcor-ip.net [84.63.47.180])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(No client certificate requested)
	by strato.aixcept.de (Postfix) with ESMTP id 7D36935C1DC;
	Sat, 27 May 2006 10:12:56 +0200 (CEST)
Date: Sat, 27 May 2006 10:11:07 +0200
Reply-To: Marcus Boerger <helly@php.net>
X-Priority: 3 (Normal)
Message-ID: <959260408.20060527101107@marcus-boerger.de>
To: Marcus Boerger <soc@marcus-boerger.de>
Cc: William Candillon <wcandillon@gmail.com>,
	Pavlo Shelyazhenko <pavlo.shelyazhenko@gmail.com>,
	Sebastian Bergmann <sb@sebastian-bergmann.de>,
	PHPdev <internals@lists.php.net>
In-Reply-To: <346329752.20060527014845@marcus-boerger.de>
References: <138663365.20060514205903@marcus-boerger.de> <454303585.20060524213714@marcus-boerger.de> <B9.57.17316.F4995744@pb1.pair.com> <44765279.8000601@akbkhome.com> <7.0.1.0.2.20060526040633.086814a0@zend.com> <4476608C.6070503@akbkhome.com> <7.0.1.0.2.20060526050422.08680c20@zend.com> <1376291629.20060526040801@marcus-boerger.de> <7.0.1.0.2.20060526120130.03c51060@zend.com> <772458214.20060527001909@marcus-boerger.de> <43b5c44e0605261609q293a87yfe1864dcb45508ec@mail.gmail.com> <346329752.20060527014845@marcus-boerger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] planning future BC Breaks - was Re: [PHP-DEV] fatal static call in php 6.0?
From: helly@php.net (Marcus Boerger)

Hello guys,

  just a short notice from google. There is a rule that disallows students
from working together. I didn't remember having seen it or heared of it on
the administrators list but if google Chris or Greg from Google say so we
can only respect that rule. In fact Chris said that the work of two students
shouldn't be overlaping. Doing part of the work twice is no problem. This
actually happens sometimes here two. In that case we take the better option
if we want it at all.

best regards
marcus

Saturday, May 27, 2006, 1:48:45 AM, you wrote:

> Hello William, Sebastian, Pavlo,

>   i guess the #line stuff is indeed a very good general addition to
> PHP. For instance this is also necessary once i made re2c capable of
> handling PHP code which a bunch of people already asked me. If that
> doesn't fit into Pavlo's concept i might do it myself somewhen in the
> upcoming future. Right now i cannot tell how good it will fit into
> Pavlo's plans. Any comment on that Pavlo?

> best regards
> marcus

> p.s.: All project/development related mails have to be open as per
> SoC conditions. To meet that requirement i added internals@lists.php.net
> as recipient. Please keep that.

> p.s.s: I am thinking of setting up an email list per SoC project to
> make it easier to follow above requirement. Thoughts on that?


> Saturday, May 27, 2006, 1:09:20 AM, you wrote:

>> On 5/26/06, Marcus Boerger <helly@php.net> wrote:
>>> Hello Zeev,
>>>
>>>   actually there was plenty of discussion prior to selecting the summer
>>> of code projects. Nonetheless we will see how it will work out. For example
>>> #line <num> <source> can easily be aded to the lexer already and doesn't
>>> require a full blown preprocessor. Versioning is very different since it
>>> should either be a real preprocessor and thus not doing any harm to php
>>> or it is a language feature and then a bunch of stuff probably has to be
>>> changed. Though maybe even then it is a simple additional state in the
>>> lexer - those tools can be so easy.
>>>
>>> Anyway you might want to contact the student.
>>>
>>> marcus
>>>
>>> Friday, May 26, 2006, 11:04:30 AM, you wrote:
>>>
>>> > Yeah I heard, but it doesn't mean it'll become a part of the language
>>> > (doesn't mean that it would not, but as usual, no discussion ;).
>>>
>>> > What Alan suggested is already a part of the language, bares no
>>> > additional overhead (both CPU cycles and brain cycles), and also
>>> > (least important point) is very easy to implement.
>>>
>>> > Zeev
>>>
>>>
>>>
>>> > At 05:08 26/05/2006, Marcus Boerger wrote:
>>> >>Hello Zeev,
>>> >>
>>> >>   actually there is a student working on a pre-processor for his summer
>>> >>of code project. And that will most likely cover versioning, too.
>>> >>
>>> >>best regards
>>> >>marcus
>>> >>
>>> >>Friday, May 26, 2006, 4:06:00 AM, you wrote:
>>> >>
>>> >> > I read it as if it was declare() ;)
>>> >>
>>> >> > I agree with Pierre that the best way to handle BC break is not to
>>> >> > introduce it, but since that's not always 100% possible, this may
>>> >> > make sense.  Of course, it'll only work with stuff that is
>>> >> > syntax-compliant with the currently running PHP version, but that
>>> >> > covers most BC breakage.
>>> >>
>>> >> > Zeev
>>> >>
>>> >> > At 04:57 26/05/2006, Alan Knowles wrote:
>>> >> >>actaully it should have been declare() - as I think the syntax for that
>>> >> >>almost works already, but yes, code doesnt get compiled if it's inside a
>>> >> >>block.
>>> >> >>
>>> >> >>Regards
>>> >> >>Alan
>>> >> >>
>>> >> >>Zeev Suraski wrote:
>>> >> >> > At 03:57 26/05/2006, Alan Knowles wrote:
>>> >> >> >> Can we start concentrating on finding a real solution to BC breaks
>>> >> >> >> rather than throwing them out there and everyone complaining?
>>> >> >> >>
>>> >> >> >> define(php5) {
>>> >> >> >>   stuff that breaks in php6
>>> >> >> >> }
>>> >> >> >> define(php6) {
>>> >> >> >>    stuff that doesnt work in PHP5
>>> >> >> >> }
>>> >> >> >
>>> >> >> > What's the semantics of that?  The code inside doesn't get executed if
>>> >> >> > it's not the define()'d PHP version?
>>> >> >> >
>>> >> >> > Zeev
>>> >>
>>> >>
>>> >>
>>> >>
>>> >>Best regards,
>>> >>  Marcus
>>>
>>>
>>>
>>>
>>> Best regards,
>>>  Marcus
>>>
>>> --
>>> PHP Internals - PHP Runtime Development Mailing List
>>> To unsubscribe, visit: http://www.php.net/unsub.php
>>>
>>>








Best regards,
 Marcus