Translating the documentation:php Manual chinese version
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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
George Schlossnagle wrote:
Being concerned about BC before there is an actual release seems silly
to me. The whole of PHP5 could be accurately described as
'experimental' atm.
+INF
Everyone who is using PHP5 right now knows (or plausibly should know)
that it is experimental. Even the text acco
At 04:30 PM 3/23/2004 -0800, Rasmus Lerdorf wrote:
On the Studlycaps issue my opinion is that it is a guideline and while it
would be nice to have consistency in the end it is ultimately up to the
extension authors to decide whether they wish to follow the guideline or
not. I have no plans on goin
Helgi Þormar Þorbjörnsson wrote:
I'm helping the guys at pear with LiveUser so i need account to commit coz all the others dev of LiveUser dont have time to take care of commiting for me so they asked me to get CVS, (pear/Perm_LiveUser)
Yup, I even already assigned a few bugs to him :-)
He should
I'm helping the guys at pear with LiveUser so i need account to commit coz all the
others dev of LiveUser dont have time to take care of commiting for me so they asked
me to get CVS, (pear/Perm_LiveUser)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.
On Tue, Mar 23, 2004 at 01:02:54PM +0100, Piotr Klaban wrote:
> During the registration phase one need to typ VISA number etc.
Just for information: everything is ok now.
I have quickly registered by sending fax directly to Software &
Support Verlag GmbH, and I hope I'll be on the conference in M
Rasmus Lerdorf wrote:
treated like a normal method in every way. In a few years when people who
have never seen PHP4 happen to create a method with the same name as the
class would get very confused if it didn't work I would think.
Good point.
I'd even extend that to allow __construct being cal
RL>> But we are getting way off the real point which is the question of whether
RL>> you should be allowed to call what I suppose is now the deprecated
RL>> constructor directly or not. I don't see a good reason why it wouldn't be
I don't see any reason to allow two constructors for a class to
CS>> I found the example a bad one too but the more I think about it the more
CS>> I believe that the language shouldn't stop you from designing your
CS>> classes in a way that you call the method which happens also to be a
CS>> constructor later again. And class methods (e.g. Log::log) are anot
On Wed, 24 Mar 2004, Stanislav Malyshev wrote:
> Hm. Do you have some example of such code? Except for object cloning
> issues which are application-wide and constructors won't help you there -
> is there some class code that should be constructed differently in PHP5
> but behave exactly the sam
Stanislav Malyshev wrote:
By "real world" I don't mean "you write up", I mean "someone really needs
it". You are defining language practice now. I think it's a bad practice to
I found the example a bad one too but the more I think about it the more
I believe that the language shouldn't stop you
RL>> There are a number of changes between PHP4 and PHP5 that aren't strictly
RL>> syntactical but rather behavioural so while the code itself will pass the
RL>> php4 syntax check, it would not run as intended and thus be PHP5 only.
Hm. Do you have some example of such code? Except for object cl
On Wed, 24 Mar 2004, Stanislav Malyshev wrote:
> RL>> The example was something like:
> RL>>
> RL>> class foo {
> RL>> function foo() {
> RL>>legacy generic constructor code
> RL>> }
> RL>> function __construct() {
> RL>>php5-specific stuff
> RL>>$this->foo()
RL>> The example was something like:
RL>>
RL>> class foo {
RL>> function foo() {
RL>>legacy generic constructor code
RL>> }
RL>> function __construct() {
RL>>php5-specific stuff
RL>>$this->foo(); // chain to legacy constructor code
RL>> }
RL>> }
RL>>
R
On Wed, 24 Mar 2004, Stanislav Malyshev wrote:
> RL>> > Why the said people won't just insert the PHP5-specific code right into
> RL>> > the constructor? Why they need the second one?
> RL>>
> RL>> To avoid having it in 2 places.
>
> What is the second place? One plase is class() constructor,
RL>> > Why the said people won't just insert the PHP5-specific code right into
RL>> > the constructor? Why they need the second one?
RL>>
RL>> To avoid having it in 2 places.
What is the second place? One plase is class() constructor, and the second
one?
--
Stanislav Malyshev, Zend Products
On Wed, 24 Mar 2004, Lukas Smith wrote:
> Rasmus Lerdorf wrote:
> > ramifications of such a change. For example, how many PEAR packages might
> > we break with this? Are any of them perhaps even in the php5 tarball
> > itself?
>
> I know this is just an example, but just to clarify:
> PEAR is
Rasmus Lerdorf wrote:
ramifications of such a change. For example, how many PEAR packages might
we break with this? Are any of them perhaps even in the php5 tarball
itself?
I know this is just an example, but just to clarify:
PEAR is currently taking a bit of a wait and see approach with php5 f
19 matches
Mail list logo
