# php5 beta - Thread: https://externals.io/message/2401 - Original archive: https://news-web.php.net/php.internals/2401 - Started by Sterling Hughes on 2003-06-19T00:15:06+00:00 - Messages: 15 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #2401 — Sterling Hughes — 2003-06-19T00:15:06+00:00 URL: https://externals.io/message/2401#2401 This is what I can think of for a concrete todo before the beta... http://www.php.net/~sterling/php5/BETA any thing i missed? anything extraeneous? -Sterling -- "Nothing is particularly hard if you divide it into small jobs." - Henry Ford --- ## #2405 — Moriyoshi Koizumi — 2003-06-19T00:51:33+00:00 URL: https://externals.io/message/2401#2405 · In reply to: #2401 Actually I'm working on the php5 version of ext/java extension :) Moriyoshi Sterling Hughes wrote: > This is what I can think of for a concrete todo before the beta... > > http://www.php.net/~sterling/php5/BETA > > any thing i missed? anything extraeneous? --- ## #2407 — Rasmus Lerdorf — 2003-06-19T02:12:04+00:00 URL: https://externals.io/message/2401#2407 · In reply to: #2405 We also need to sort out the mbstring license mess. We cannot distribute code that is under the LGPL and modified by us. The relevant clauses from the LGPL: 2. You may modify your copy or copies of the Library or any portion of it, thus forming a work based on the Library, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions: a) The modified work must itself be a software library. b) You must cause the files modified to carry prominent notices stating that you changed the files and the date of any change. c) You must cause the whole of the work to be licensed at no charge to all third parties under the terms of this License. ... We do not meet a) and c) here. Specifically mbregex and mbfilter* have this problem. The code in them is under the LGPL and we have modified these files. Now, if we found a way around putting modifications directly into these files and simply wrapped them transparently, then we are ok as per this clause in the LGPL: 1. You may copy and distribute verbatim copies of the Library's complete source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and distribute a copy of this License along with the Library. The other option if a transparent wrapper can't be done is to get the permission of the authors to distribute these files under the PHP license. -Rasmus --- ## #2410 — Sterling Hughes — 2003-06-19T03:31:15+00:00 URL: https://externals.io/message/2401#2410 · In reply to: #2407 I've added the mb stuff to the list. Can the extension itself be considered a complete work? Therefore by distributing the extension (under the LGPL) without modifications with PHP, we essentially keep the cancer isolated? -Sterling > We also need to sort out the mbstring license mess. We cannot distribute > code that is under the LGPL and modified by us. The relevant clauses from > the LGPL: > > 2. You may modify your copy or copies of the Library or any portion of > it, thus forming a work based on the Library, and copy and distribute such > modifications or work under the terms of Section 1 above, provided > that you also meet all of these conditions: > > a) The modified work must itself be a software library. > b) You must cause the files modified to carry prominent notices > stating that you changed the files and the date of any change. > c) You must cause the whole of the work to be licensed at no charge > to all third parties under the terms of this License. > ... > > We do not meet a) and c) here. Specifically mbregex and mbfilter* have > this problem. The code in them is under the LGPL and we have modified > these files. > > Now, if we found a way around putting modifications directly into these > files and simply wrapped them transparently, then we are ok as per this > clause in the LGPL: > > 1. You may copy and distribute verbatim copies of the Library's complete > source code as you receive it, in any medium, provided that you > conspicuously and appropriately publish on each copy an appropriate > copyright notice and disclaimer of warranty; keep intact all the > notices that refer to this License and to the absence of any warranty; and > distribute a copy of this License along with the Library. > > The other option if a transparent wrapper can't be done is to get the > permission of the authors to distribute these files under the PHP license. > > -Rasmus -- "Programming today is a race between software engineers stirring to build bigger and better idiot-proof programs, and the universe trying to produce bigger and better idiots. So far, the universe is winning." - Unknown --- ## #2412 — Sterling Hughes — 2003-06-19T03:46:01+00:00 URL: https://externals.io/message/2401#2412 · In reply to: #2411 Sure. PECL is a proof of that. ;-) -Sterling > > > […] > > We would have to argue that the extension is a "software library". Which > in a sense it is I guess. > > -Rasmus -- "C makes it easy to shoot yourself in the foot; C++ makes it harder, but when you do, it blows away your whole leg." - Bjarne Stroustrup --- ## #2411 — Rasmus Lerdorf — 2003-06-19T03:47:58+00:00 URL: https://externals.io/message/2401#2411 · In reply to: #2410 > I've added the mb stuff to the list. > > Can the extension itself be considered a complete work? Therefore by > distributing the extension (under the LGPL) without modifications with > PHP, we essentially keep the cancer isolated? We would have to argue that the extension is a "software library". Which in a sense it is I guess. -Rasmus --- ## #2426 — Per Lundberg — 2003-06-19T14:32:28+00:00 URL: https://externals.io/message/2401#2426 > "Marcus BRger" wrote in message > news:1066290321.20030619154615@post.rwth-aachen.de... > > […] > add my +1 to the consensus. Me too. OOP without proper use of exceptions is a poor man's choice. +1. -- Best regards, Per Lundberg / Capio ApS Phone: +46-18-4186040 Fax: +46-18-4186049 Web: http://www.nobolt.com --- ## #2440 — Shane Caraveo — 2003-06-19T18:45:45+00:00 URL: https://externals.io/message/2401#2440 +0 While I really like the idea, auto-exceptions for errors would mess up library code that isn't written to use exceptions. If that problem can be dealt with correctly, then I'd be +1. Otherwise, we need a new error level. Shane Marcus Börger wrote: > Hello Sterling, > > We need exceptions instead of errors whenever a try/catch block is > entered or a constructor gets called. This is a very easy thing to > implement but we need a consensus before doing so. > > regards > marcus > > p.s.: And i'd still like to have final classes > > Thursday, June 19, 2003, 2:15:06 AM, you wrote: > > SH> This is what I can think of for a concrete todo before the beta... > > SH> http://www.php.net/~sterling/php5/BETA > > SH> any thing i missed? anything extraeneous? > > SH> -Sterling > SH> -- > SH> "Nothing is particularly hard if you divide it into small jobs." > SH> - Henry Ford --- ## #2442 — Shane Caraveo — 2003-06-19T18:57:15+00:00 URL: https://externals.io/message/2401#2442 I knew I should have kept my mouth shut... Marcus Börger wrote: > Hello Shane, > > just to repeat there weren't any exceptions in php4 Yes, you don't have to tell me the obvious. and the things > that'll use exceptions in php5 will require full rewrite anyway. So i > don't see any problem. try { function_call_to_some_preexisting_library_that_doesnt_do_exceptions() } catch(e) { } With auto exceptions, that breaks any error control the existing library might have. So to make my opinion a bit stronger, -10 unless someone is clever enough to make it work in all instances. Shane > Thursday, June 19, 2003, 8:45:45 PM, you wrote: > > SC> +0 While I really like the idea, auto-exceptions for errors would mess > SC> up library code that isn't written to use exceptions. If that problem > SC> can be dealt with correctly, then I'd be +1. Otherwise, we need a new > SC> error level. > SC> Shane > > SC> Marcus Börger wrote: > > > […] --- ## #2474 — Andi Gutmans — 2003-06-21T09:14:28+00:00 URL: https://externals.io/message/2401#2474 · In reply to: #2401 At 03:46 PM 6/19/2003 +0200, Marcus Börger wrote: >Hello Sterling, > >We need exceptions instead of errors whenever a try/catch block is >entered or a constructor gets called. This is a very easy thing to >implement but we need a consensus before doing so. You can always throw the exception manually in the constructor. The bottom line is that right now no one seems to have the answer on what should be done without making a complete mess out of the error/exception handling in PHP. I suggest that in the meanwhile we keep things the way they are, get the beta out the door and see what feedbacks we get and what catches on strongly in the dev community. >p.s.: And i'd still like to have final classes No big deal IMO and not necessary for the beta. Andi --- ## #2475 — Andi Gutmans — 2003-06-21T09:16:22+00:00 URL: https://externals.io/message/2401#2475 · In reply to: #2401 At 08:15 PM 6/18/2003 -0400, Sterling Hughes wrote: >This is what I can think of for a concrete todo before the beta... > >http://www.php.net/~sterling/php5/BETA > >any thing i missed? anything extraeneous? These are very small tasks. I suggest we assign owners to each and aim for the 30th of June for wrapping up a Beta. Do we have volunteers? Andi --- ## #2516 — Terje Torkelsen — 2003-06-21T23:32:59+00:00 URL: https://externals.io/message/2401#2516 · In reply to: #2401 On Thu, 19 Jun 2003 2:15:06 +0200, Sterling Hughes wrote (in message <1055981706.8233.10.camel@hasele>): > This is what I can think of for a concrete todo before the beta... > > http://www.php.net/~sterling/php5/BETA > > any thing i missed? anything extraeneous? > > -Sterling > how about bug #21669? can cause big troubles... --- ## #2521 — Andi Gutmans — 2003-06-22T05:39:14+00:00 URL: https://externals.io/message/2401#2521 · In reply to: #2401 At 01:32 AM 6/22/2003 +0200, Terje Torkelsen wrote: >On Thu, 19 Jun 2003 2:15:06 +0200, Sterling Hughes wrote >(in message <1055981706.8233.10.camel@hasele>): > > > […] > >how about bug #21669? can cause big troubles... I'll try and take a look at this one. Andi --- ## #2530 — Zeev Suraski — 2003-06-22T11:00:23+00:00 URL: https://externals.io/message/2401#2530 · In reply to: #2401 At 02:32 22/06/2003, Terje Torkelsen wrote: >On Thu, 19 Jun 2003 2:15:06 +0200, Sterling Hughes wrote >(in message <1055981706.8233.10.camel@hasele>): > > > […] > >how about bug #21669? can cause big troubles... It's fixed! Zeev --- ## #2531 — Terje Torkelsen — 2003-06-22T11:54:09+00:00 URL: https://externals.io/message/2401#2531 · In reply to: #2530 On Sun, 22 Jun 2003 13:00:23 +0200, Zeev Suraski wrote (in message <5.1.0.14.2.20030622140018.0a9792a0@localhost>): > At 02:32 22/06/2003, Terje Torkelsen wrote: > > […] > > It's fixed! > > Zeev > nice! works perfect so far.