Hi Wez,
I think this is an extremely cool effort (although I haven't played around
with it quite yet).
Is win32build.zip updated with all of the latest and greatest including
libXML2? I really think we should have a big package with everything
inside. It's usually a pain when I want to build ce
Andi Gutmans wrote:
> Is win32build.zip updated with all of the latest and greatest
> including libXML2?
No, it isn't.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareentwicklung-mit-php5.de/
--
At 09:30 AM 12/3/2003 +0100, Sebastian Bergmann wrote:
Andi Gutmans wrote:
> Is win32build.zip updated with all of the latest and greatest
> including libXML2?
No, it isn't.
Any chance of updating it or making an additional package for ppl who have
a DSL line :)
Andi
--
PHP Internals - PHP Run
Andi Gutmans wrote:
> Any chance of updating it or making an additional package for ppl who
> have a DSL line :)
I only have a "hacked" build of libxml2/libxslt here that someone from
IRC (can't remember who) sent me a while ago.
Anyhow, I think it would be best to maintain the Win32 build
We should use rsync for this; I wonder if Edin can do
the honours with his win32 build treasure chest? :-)
--Wez
- Original Message - > Wez Furlong wrote:
> > Finally, you need the php_build dir that contains all the
> > headers and libraries for the things that php is linked
> > against;
Derick Rethans wrote:
> -[6] Method names follow the 'studlyCaps'
This is insane.
Whether you like it or not, most people who use programming languages
that support the paradigm of object-orientation use studlyCaps (or
whatever you want to call them).
I think it is not a good idea to s
> From: admin [mailto:admin] On Behalf Of Sebastian Bergmann
> Sent: Wednesday, December 03, 2003 10:36 AM
> Derick Rethans wrote:
> > -[6] Method names follow the 'studlyCaps'
>
> This is insane.
>
> Whether you like it or not, most people who use programming languages
> that support the
On Wed, 3 Dec 2003, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > -[6] Method names follow the 'studlyCaps'
>
> This is insane.
>
> Whether you like it or not, most people who use programming languages
> that support the paradigm of object-orientation use studlyCaps (or
> whatever
On Wednesday, Dec 3, 2003, at 10:12 Europe/Copenhagen, Derick Rethans
wrote:
derick Wed Dec 3 04:12:39 2003 EDT
Modified files:
/php-srcCODING_STANDARDS
Log:
- I am sure I reverted this before
No you didn't. Care to elaborate on this change?
Edin
--
PHP Internals - PHP Runtime
On Wed, 3 Dec 2003 10:42:33 +0100 (CET)
Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Dec 2003, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > -[6] Method names follow the 'studlyCaps'
> >
> > This is insane.
> >
> > Whether you like it or not, most people who use program
Pierre-Alain Joye wrote:
> Meeting where you, Sebastian Bergmann, Hartmut Holzgraefe, Jeroen
> Houben, Wolfram Kriesing, Jan Lehnardt, George Schlossnagle,
> Lukas Smith, Markus Wolff and Jani were present (add those I forgot ;)
> ), and all people online via IRC.
I was not at this meeting.
--
Derick Rethans <[EMAIL PROTECTED]> wrote:
> On Wed, 3 Dec 2003, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > -[6] Method names follow the 'studlyCaps'
> >
> > This is insane.
> >
> > Whether you like it or not, most people who use programming languages
> > that support the pa
On Wed, 03 Dec 2003 19:13:13 +0900
Moriyoshi Koizumi <[EMAIL PROTECTED]> wrote:
> Derick Rethans <[EMAIL PROTECTED]> wrote:
>
> > On Wed, 3 Dec 2003, Sebastian Bergmann wrote:
> >
> > > Derick Rethans wrote:
> > > > -[6] Method names follow the 'studlyCaps'
> > >
> > > This is insane.
> > >
>
On Wednesday, Dec 3, 2003, at 11:13 Europe/Copenhagen, Moriyoshi
Koizumi wrote:
Derick Rethans <[EMAIL PROTECTED]> wrote:
On Wed, 3 Dec 2003, Sebastian Bergmann wrote:
Derick Rethans wrote:
-[6] Method names follow the 'studlyCaps'
This is insane.
Whether you like it or not, most people wh
Pierre-Alain Joye wrote:
See http://pear.php.net/news/meeting-2003-summary.php. Especially this
line:
"PHP object-oriented APIs should follow the PEAR coding standards."
i don't remember this and even if i did i don't think a PEAR project
meeting is able to take any decision on how PHP core develop
Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a
recommendation for the APIs exposed by PHP.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi
> > As far as I'm concerned, no such agreement that it is a requirement
> > was made so far on this list... (correct me if I'm wrong)
>
> Well, no idea about when we should consider something agreed or not.
> However here is the archives:
> http://marc.theaimsgroup.com/?l=php-dev&m=10571567170
Magnus Määttä <[EMAIL PROTECTED]> wrote:
> IIRC there was an agreement a few months ago to use studlyCaps after
> some lengthy thread..
If so, I see no problem then. I'm just afraid of an implicit and
kind of informal agreement off the list.
Moriyoshi
--
PHP Internals - PHP Runtime Development
On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote:
> At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote:
> >For the next 18-24 months, we are going to have to deal with code
> >running in both PHP 4 and 5. Why not declare "var" an alias for
> >"public", not throw E_STRICT for it and be done with it?
On Tue, 2003-12-02 at 18:43, Marcus Boerger wrote:
> Hello Christian,
>
> Tuesday, December 2, 2003, 1:14:12 PM, you wrote:
>
> > Andi Gutmans wrote:
> >> E_STRICT will be disabled by default. It is only meant for people who
> >> want to be sure that they are using the recommended methods, and t
On Wed, 3 Dec 2003, Stig S. Bakken wrote:
> On Tue, 2003-12-02 at 12:51, Andi Gutmans wrote:
> > At 11:40 PM 12/1/2003 +0100, Stig S. Bakken wrote:
> > >For the next 18-24 months, we are going to have to deal with code
> > >running in both PHP 4 and 5. Why not declare "var" an alias for
> > >"pub
On Mon, 2003-12-01 at 21:47, Andi Gutmans wrote:
> At 03:32 PM 12/1/2003 -0500, Daniel Convissor wrote:
> >On Mon, Dec 01, 2003 at 10:15:46PM +0200, Andi Gutmans wrote:
> > >
> > > I don't quite understand the problem. E_STRICT was only meant for people
> > > who really want to be pedantic. I think
Stig S. Bakken wrote:
The goal here is to assure smooth transition from PHP 4 to PHP 5 for
PEAR users. To me that means not having to use version_compare() or
have different versions of files for PHP 4 and 5.
I think you slightly mix up PEAR developers and PEAR users but I
completely agree with y
Pierre-Alain Joye wrote:
And now I'm wondering why that suddenly becomes ugly and, as pointed
Sebastion, why PHP should follow different things than 99.% of
others OO langages.
one reason might bee that we do not have case sensitive function names
so that it is possible to use whatever "CAPSula
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 11:48 AM
> Pierre-Alain Joye wrote:
> > And now I'm wondering why that suddenly becomes ugly and, as pointed
> > Sebastion, why PHP should follow different things than 99.% of
> > others OO langages.
>
On Wednesday, Dec 3, 2003, at 11:33 Europe/Copenhagen, Sascha Schumann
wrote:
Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a
recommendation for the APIs exposed by PHP.
Are you suggesting that we do not have a standard here as Derick is
suggesting, or to keep the current PHP codi
Sebastian Bergmann wrote:
Derick Rethans wrote:
-[6] Method names follow the 'studlyCaps'
This is insane.
It's not. Using underscores for all native PHP functions seperates them
nicely from PHP based code, eg. PEAR code.
php_native_func()
myFunc()
or even:
obj->php_native_func()
obj->myFunc
On Wed, 03 Dec 2003 11:52:35 +0100
Ulf Wendel <[EMAIL PROTECTED]> wrote:
> php_native_func()
> myFunc()
We are not talking about function names but methods.
> or even:
>
> obj->php_native_func()
> obj->myFunc()
Quick thought, does that work with overload? See Lukas post.
pierre
--
PHP Inter
Lukas Smith wrote:
Aside from that yes it will be a major problem for PEAR if objects don't
follow studyCaps as this means we will have to either kick our CS or wrap
objects instead of just exending them.
i agree that it is way to late now for changing things in PEAR
but i still think it was a bad
On Wed, 3 Dec 2003, Edin Kadribasic wrote:
>
> On Wednesday, Dec 3, 2003, at 11:33 Europe/Copenhagen, Sascha Schumann
> wrote:
>
> > Heavy -1 on making hardTooTypeAndEvenWorseToReadCaps a
> > recommendation for the APIs exposed by PHP.
>
> Are you suggesting that we do not have a standard
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 12:52 PM
> Lukas Smith wrote:
> > Aside from that yes it will be a major problem for PEAR if objects don't
> > follow studyCaps as this means we will have to either kick our CS or
> wrap
> > objects instead
I can nuke E_STRICT altogether if u guys want.
It's kind of a shame because I thought it might be nice for purists. I
don't understand why it bothers ppl so much when they don't have to use it.
At 12:18 PM 12/3/2003 +0100, Christian Schneider wrote:
Stig S. Bakken wrote:
The goal here is to assur
On Wed, 3 Dec 2003, Andi Gutmans wrote:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
Please keep it in.
Derick
--
PHP Internals - PHP Runti
Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote:
> PS: can you prove that 99.% figure? i'd believe a value of maybe
> 80% but definetly not 99.% ;)
Underscore-delimited identifiers are preferred in Ada and Ruby, while
they don't seem to be in Java, Objective C, SmallTalk, C# and ECMASc
On Wednesday 03 December 2003 12.59, Derick Rethans wrote:
> On Wed, 3 Dec 2003, Andi Gutmans wrote:
> > I can nuke E_STRICT altogether if u guys want.
> > It's kind of a shame because I thought it might be nice for purists. I
> > don't understand why it bothers ppl so much when they don't have to
Moriyoshi Koizumi wrote:
Underscore-delimited identifiers are preferred in Ada and Ruby, while
they don't seem to be in Java, Objective C, SmallTalk, C# and ECMAScript.
(How about Python...?)
i guess i finally identified the original source of studlyCaps: SmallTalk
as far as i can tell from the
Pierre-Alain Joye wrote:
On Wed, 03 Dec 2003 11:52:35 +0100
Ulf Wendel <[EMAIL PROTECTED]> wrote:
obj->php_native_func()
obj->myFunc()
Quick thought, does that work with overload? See Lukas post.
I'm not sure if I understand this. Is there any warranty that overloaded
stuff will always follow t
Hello,
On Wed, 03 Dec 2003 14:02:00 +0100
Ulf Wendel <[EMAIL PROTECTED]> wrote:
> Nevertheless I preferr PHP not to use studyCaps for it's native
> functions/methods/whatever. It seperates the build-in functionality
> nicely from my code.
I like the counter and nicely move from PHP classes to
Pierre-Alain Joye wrote:
This BC thingies in PHP5 sound always weird or silly to me (in most
cases). Why in the world do we need a major release if on each case we
have to take care of php4?
One of the reasons that you don't see PHP 3 in use anymore is that
the transition was so easy. Now that we h
On Wed, 03 Dec 2003 14:30:08 +0100
Hartmut Holzgraefe <[EMAIL PROTECTED]> wrote:
> One of the reasons that you don't see PHP 3 in use anymore is that
> the transition was so easy. Now that we have even more installations
> out there and a lot of open projects that run on PHP 4 it is even
> more im
Here is more on the history of uglyCaps:
http://www.testingcraft.com/cgi-bin/wiki.cgi?StudlyCaps
Quote:
``Round about 1978, I remember using a terminal, said to be "a
European one", that displayed the underscore character
as a backward arrow. Some programming
Quoting Andi Gutmans <[EMAIL PROTECTED]>:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
>
I am with Derick, it should be in. The non-purist wo
Thanks for the history, always funny :)
On Wed, 3 Dec 2003 15:05:19 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> Fortunately, we can avoid falling into that trap. PHP
> supports underscores, and terminals which cannot display the
> character correctly don't prevail any l
Pierre-Alain Joye wrote:
OK, then mail to java (for the java binder), microsoft (com binder and
w32 ext), libxml (and related tools), w3c (dom and others std), python
(python binder), postgres, wxwindows (should come as
well soon or later)... teams and ask them to move to the modern times as
well ;
> On Wed, 3 Dec 2003 15:05:19 +0100 (CET)
> Sascha Schumann <[EMAIL PROTECTED]> wrote:
>
> > Fortunately, we can avoid falling into that trap. PHP
> > supports underscores, and terminals which cannot display the
> > character correctly don't prevail any longer.
>
> If you consider this
Pierre-Alain Joye wrote:
> On Wed, 03 Dec 2003 14:02:00 +0100
> Ulf Wendel <[EMAIL PROTECTED]> wrote:
>>Most PHP extension have a functional interface. If some extension will
>>become an OO API in the future this API should not differ from the
>>functional API. I don't see a good reason why I we sh
On Wed, 3 Dec 2003 15:44:52 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> The point is that uglyCaps are backwards, a hack/workaround
> for a missing feature in a language.
>
> uglyCaps have no inherent advantage which should be
> considered by those advocating their wi
Pierre-Alain Joye wrote:
And except StudlyCaps is ugly and foo_bar is modern, any realistic
and objective pros to keep foo_bar?
readability
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Fixed.
> bison --output=Zend/zend_ini_parser.\ -v -d -p ini_
> Zend/zend_ini_parser
> .y
> Zend/zend_ini_parser.y: conflicts: 4 shift/reduce
> Zend/zend_ini_parser.y: warning: conflicting outputs to file
> `Zend/zend_ini_pars
> er.\\'
> bison: cannot open file `Zend/zend_ini_parser.\': No
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:03 PM
> Pierre-Alain Joye wrote:
> > And except StudlyCaps is ugly and foo_bar is modern, any realistic
> > and objective pros to keep foo_bar?
>
> readability
I dont find it unreadable.
Anyways this
> Well, as (hopefully) a last post from me in this thread, the fact is the
> "UglyCaps" is widely used, with PHP and others OO langages. The fact
> is that is somehow a de facto standard and ease our life to
> bind/port/extend/whatever existing codes/applications/libraries using
> php.
Look, m
> From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:16 PM
> > Well, as (hopefully) a last post from me in this thread, the fact is the
> > "UglyCaps" is widely used, with PHP and others OO langages. The fact
> > is that is somehow a de facto standard and ease
> Do you think this inconsistency is worth it, even if it turns out that most
> of our bindings turn out to choose studyCaps?
Certainly. And I am pretty sure that many binding authors
will understand why uglyCaps are largely inferior in the area
of comprehension.
> No doubt the non s
Lukas Smith wrote:
Pierre-Alain Joye wrote:
And except StudlyCaps is ugly and foo_bar is modern, any realistic
and objective pros to keep foo_bar?
readability
I dont find it unreadable.
it is not unreadable but it is definetly *less* readble
--
Hartmut Holzgraefe <[EMAIL PROTECTED]>
--
PHP
> From: Hartmut Holzgraefe [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:31 PM
> Lukas Smith wrote:
> >>Pierre-Alain Joye wrote:
> >>
> >>>And except StudlyCaps is ugly and foo_bar is modern, any realistic
> >>>and objective pros to keep foo_bar?
> >>
> >>readability
> >
>
On Wed, 3 Dec 2003 16:16:14 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> > Well, as (hopefully) a last post from me in this thread, the fact is
> > the"UglyCaps" is widely used, with PHP and others OO langages. The
> > fact is that is somehow a de facto standard and ease our life to
>
> The fact that PEAR has a serious problem extending non studlyCap objects is
> probably something a lot of people in PHP core don't care about.
Please elaborate.
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:39 PM
> > The fact that PEAR has a serious problem extending non studlyCap objects
> is
> > probably something a lot of people in PHP core don't care about.
>
> Please elaborate.
Well if I extend a clas
Wez Furlong wrote:
> Fixed.
Yes, but now it fails with
NMAKE : fatal error U1073: 'ext\standard\parsedate.c' konnte nicht
erstellt werd
en
Stop.
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://professionelle-softwareen
On Wed, 03 Dec 2003 16:41:24 +0100
Sebastian Bergmann <[EMAIL PROTECTED]> wrote:
> Wez Furlong wrote:
> > Fixed.
>
> Yes, but now it fails with
>
> NMAKE : fatal error U1073: 'ext\standard\parsedate.c' konnte nicht
> erstellt werd
> en
> Stop.
means "... cannot be generated Stop." ;-)
--
PH
On Wed, 3 Dec 2003, Lukas Smith wrote:
> > From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 03, 2003 4:39 PM
>
> > > The fact that PEAR has a serious problem extending non studlyCap objects
> > is
> > > probably something a lot of people in PHP core don't care about.
>
> From: Derick Rethans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:46 PM
> On Wed, 3 Dec 2003, Lukas Smith wrote:
>
> > > From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, December 03, 2003 4:39 PM
> >
> > > > The fact that PEAR has a serious problem ext
On Wed, 3 Dec 2003, Lukas Smith wrote:
> > From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 03, 2003 4:39 PM
>
> > > The fact that PEAR has a serious problem extending non studlyCap objects
> > is
> > > probably something a lot of people in PHP core don't care about.
>
> From: Lukas Smith [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:46 PM
> > From: Derick Rethans [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 03, 2003 4:46 PM
>
> > On Wed, 3 Dec 2003, Lukas Smith wrote:
> >
> > > > From: Sascha Schumann [mailto:[EMAIL PROTECTED]
>
Hi Wez,
now that the dependency on VC has been dropped, what would it
take to get mingw32 build support?
- Sascha
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
> From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 4:53 PM
>
> On Wed, 3 Dec 2003, Lukas Smith wrote:
>
> > > From: Sascha Schumann [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, December 03, 2003 4:39 PM
> >
> > > > The fact that PEAR has a serious problem e
On Wed, 3 Dec 2003 17:01:23 +0100 (CET)
Sascha Schumann <[EMAIL PROTECTED]> wrote:
> Hi Wez,
>
> now that the dependency on VC has been dropped, what would it
> take to get mingw32 build support?
Should be really great :).
By the way (or a bit OT), I got little little success by run
Lukas Smith wrote:
Actually I think it is even an
advantage because it makes me differentiate procedural code from OO code
more easily.
that would be an argument for C++ where calls to member functions
look exactly like calls to functions from the global scope
in PHP the difference becomes rather
Andi Gutmans wrote:
I can nuke E_STRICT altogether if u guys want.
It's kind of a shame because I thought it might be nice for purists. I
don't understand why it bothers ppl so much when they don't have to use it.
Please keep it... It will be usefull for people willing to write "good
PHP5 code".
When I tried to enable win32 specific extensions (such as COM)
under cygwin, I found that a lot of the win32 api headers were
missing, so the build failed.
I suspect that the same problem will manifest with mingw32.
It's nothing that downloading the platform SDK won't solve,
but if you download th
On Wed, 3 Dec 2003, Wez Furlong wrote:
> When I tried to enable win32 specific extensions (such as COM)
> under cygwin, I found that a lot of the win32 api headers were
> missing, so the build failed.
Cygwin is a Unix portability layer, not a win32. :)
mingw's header set should be fairly
> > When I tried to enable win32 specific extensions (such as COM)
> > under cygwin, I found that a lot of the win32 api headers were
> > missing, so the build failed.
>
> Cygwin is a Unix portability layer, not a win32. :)
Sure, but you can use the win32 api from there, and some of
the heade
Hello Andi,
Wednesday, December 3, 2003, 12:57:19 PM, you wrote:
> I can nuke E_STRICT altogether if u guys want.
> It's kind of a shame because I thought it might be nice for purists. I
> don't understand why it bothers ppl so much when they don't have to use it.
Args, please let it in. It hel
Wez Furlong wrote:
You also need the Microsoft build tools (cl.exe, link.exe and nmake.exe).
These are freely available as part of the Platform SDK, but also
come with VC++/Visual Studio.
Just to be sure... I have VC6, so I don't need those, but are you
talking about this SDK?
http://www.microsof
Today I got the error from bug #25916 several times on our webserver.
Looking through the code I found out the following:
* It depends NOT on the fact if there is a parameter to get_browser() or not
* It happens sometimes when server is very heavy loaded, the homepage of
the domain uses the get_b
Yes, thats the one, but please don't do that (yet!).
I want to stabilize things a little before it goes "public";
I don't mind dealing with a handful of the core developers,
but certainly can't handle people asking me how to install
the SDK etc. etc. right now.
--Wez.
> > You also need the Micros
Hello Uwe,
Wednesday, December 3, 2003, 6:06:13 PM, you wrote:
> Today I got the error from bug #25916 several times on our webserver.
> Looking through the code I found out the following:
> * It depends NOT on the fact if there is a parameter to get_browser() or not
> * It happens sometimes whe
We have thread-safe hashes in php5; browscap should probably
use one of those there. If you want to roll your own protection,
take a look at tsrm_mutex_lock() and tsrm_mutex_unlock() and how
they are used in ext/yaz.
--Wez.
- Original Message -
From: "Uwe Schindler" <[EMAIL PROTECTED]>
On 2003/12/04, at 2:06, Uwe Schindler wrote:
This evening I will try to put a mutex at the beginning of get_browser
to prevent more threads running at the same time there. But as I see
this, this zend_hash_apply function is used very often could there be
other effects if a global variable is a
Wez Furlong wrote:
Yes, thats the one, but please don't do that (yet!).
I want to stabilize things a little before it goes "public";
I don't mind dealing with a handful of the core developers,
but certainly can't handle people asking me how to install
the SDK etc. etc. right now.
Ooops.. I do under
One solution (attached is the patch, if nobody has someone against it I
will apply it):
I switch off the recursion protection for the browscap hash in
zend_hash_init_ex because this hash has no recursive things in it and is
not modified after it is created.
Uwe
At 18:06 03.12.2003, Uwe Schindl
> On Tue, Dec 02, 2003 at 11:40:18PM -, Wez Furlong wrote:
> Platform SDK??? Ah, Google to the rescue...
> http://www.google.com/search?q=+site:www.microsoft.com+platform+sdk
[snip rant about MS]
> Wez, can you pleaes help point me to the right place? Guess it'd be handy
> to have this exp
I'd like this system to replace the .dsp's ready for when PHP 5
goes gold; I'm not sure what the others think.
However, I don't think we have time to get it working for beta 3,
so someone still needs to edit all those .dsp files, and change
php4 to php5 in main/config.w32.h for the install dir.
-
Hi Wez:
On Wed, Dec 03, 2003 at 05:28:43PM -, Wez Furlong wrote:
>
> I certainly
> can't support someone who has never heard of it before install it :-)
I'm just asking where you downloaded it from, please. For example, did
you use the aforementioned URI but with IE? Or do you have some ot
> I'm just asking where you downloaded it from, please. For example, did
> you use the aforementioned URI but with IE? Or do you have some other
> URI?
I didn't download it; I have VC6 and VS.Net 2003.
Olivier Hill posted a link to the correct page which is one
of those you mentioned in your MS
Wez Furlong wrote:
Olivier Hill posted a link to the correct page which is one
of those you mentioned in your MS rant iirc.
And you need IE 5+ to access the page.. Since it's ActiveX powered with
"Famous Microsoft Auto-Install via the web" crap. Browsing with Mozilla
will only give you a warning.
On Wed, 3 Dec 2003, Edin Kadribasic wrote:
>
>On Wednesday, Dec 3, 2003, at 10:12 Europe/Copenhagen, Derick Rethans
>wrote:
>
>> derick Wed Dec 3 04:12:39 2003 EDT
>>
>> Modified files:
>> /php-src CODING_STANDARDS
>> Log:
>> - I am sure I reverted this before
>
>No you d
Wez Furlong wrote:
However, I don't think we have time to get it working for beta 3,
so someone still needs to edit all those .dsp files, and change
php4 to php5 in main/config.w32.h for the install dir.
Maybe we could commit this file for PHP5.
As for the dsp/dsw, we have to include new file in C
On Wed, 3 Dec 2003, Stig S. Bakken wrote:
>What we're trying to avoid is to force every package maintainer to roll
>PHP 5 specific releases for packages that still support PHP 4. Smooth
>transition requires that one package at a time can be transitioned, or
>we would create a dependency mess out
Sorry if it has been discussed before, but how is the
question about __clone accept arguments ???
It would permit a better control when clonning
objects, like dinamically setting properties.
Sure its is possible using wrappers, but would be
better if the function supports that.
class clonable{
Uwe Schindler wrote:
> One solution (attached is the patch, if nobody has someone against it I
> will apply it):
> I switch off the recursion protection for the browscap hash in
> zend_hash_init_ex because this hash has no recursive things in it and is
> not modified after it is created.
>
> Uwe
Uwe,
I'm having problems reproducing the error. I tried hammering a get_browser()
function with apachebench a couple of times with the options (-n 1000 -c
25) and they all returned the same content length, so I'm assuming there
was no error in any of them.
I'm using iPlanet-WebServer-Enterprise/
It doesn't accept arguments. An object should know how to clone itself
without additional information. If you want a method which does something
other than cloning then define your own method.
Andi
At 10:14 AM 12/3/2003 -0800, Eduardo R. Maciel wrote:
Sorry if it has been discussed before, but
Hey,
I think we should come to closure on this discussion because it's becoming
hard to catch up with.
I'd like to finalize this issue for PHP (the C part) so that we can release
Beta 3. I think what PEAR does is really up to the PEAR dev team (although
I think it would be nice for them to be c
My vote is on StudlyCaps for class method and attribute names. This is
the standard in many OO languages (SmallTalk, C#, Java - as a
parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
of the first I'm aware of) had anything to do with _ rendering), and
while we do not need
I know the valids decision votes will be from the core
developers (wich I am not). But I´d like to expose my
suggestion:
- PHP object oriented parts, like classnames,
methods, atributes, etc could use studlyCaps as almost
whole world use to with OO code.
- Php procedural parts, like functions
On Wed, 2003-12-03 at 15:58, George Schlossnagle wrote:
> My vote is on StudlyCaps for class method and attribute names. This is
> the standard in many OO languages (SmallTalk, C#, Java - as a
> parenthetical I don't think that SmallTalks adoption of StudlyCaps (one
> of the first I'm aware of)
If the votes already takes place, I vote on studlyCaps as a
recommendation for PHP OO API, because of consistency with the
existing PEAR conventions.
I like underscore_delimited_style, but embracing two different
standards will definitely disgust not a few number of people.
Neither Readability nor
Hello Andi,
i am pro studlyCaps.
1st it eases PEAR development towards php5.
2nd we choose not to do so as we couldn't show errors and all in original
casing, now we can we decided to use studlyCaps and we agreed upon even in
our CODING_STYLE (and we did whether or not that rule was removed today)
+1 on studlyCaps
pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
1 - 100 of 133 matches
Mail list logo
