I'm -1 for suckyCaps.
--Jani
p.s. Why not a mix, e.g. PHP_Object =)
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Wez Furlong wrote:
> Search for pecl extensions under php-src/pecl as a convenience for
> pecl developers.
Why not assume pecl/ being a sibling directory to php-src/?
--
Sebastian Bergmann
http://sebastian-bergmann.de/ http://phpOpenTracker.de/
Das Buch zu PHP 5: http://prof
Hi,
stdlib.h is included in line 106 of bindlib_w32\conf\portability.h. This
causes the linker to look for __pctype and __mb_cur_max. This is not a
problem for the old style builds but with Wez' new build system it causes
a linking problem.
Removing line 106 form this file solves the problem and
please note:
> - Almost all external technology wich PHP will
>interact now or in the near future uses studlyCaps.
I mean:
- Almost all #OO# external technology wich PHP will
interact now or in the near future uses studlyCaps.
__
Do you Yahoo!?
Free Pop-Up Blocker
Why does not everybody consider the existent facts,
and not what one likes and other does not like?
It would be more logical.
The facts:
- There are already extensions that use
studlyCaps(DOM, mysqli, and others), and probably WONT
change.
- In the future, probably several other external OO
ex
Melvyn Sopacua wrote:
On Wednesday 03 December 2003 23:35, Michael Walter wrote:
Markus Fischer wrote:
> [...]
I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland written
method calls.
- Markus (and his
On Sun, 30 Nov 2003, Andi Gutmans wrote:
> I kind of agree with Andrei here. We discussed in the past that
> __toString() will not propogate to every place in the engine where we check
> for IS_STRING but will only effect print.
> I think getting into this is a bad idea. If the old parameter pass
On Mon, 01 Dec 2003, Marcus Boerger wrote:
> No, when the object does not offer a valid string conversion nothing will
> change compared to what we had before. So the only thing done is that you
> now can implement objects that can be used as strings like simplexml_element.
> An extension like that
On Wednesday 03 December 2003 23:35, Michael Walter wrote:
> Markus Fischer wrote:
> > [...]
> >
> > I like the initial argument brought up by Mr. Wendel, namely to
> > easily differentiate between PHP method calls and userland written
> > method calls.
> >
> > - Markus (and his co
On Thu, 4 Dec 2003, Andi Gutmans wrote:
> Can we aim for a definitive 9th December (my birthday)? After Beta 3 we
> would then code freeze and prepare for RC1.
I am cool with the Beta 3 date, but I think it would be helpful if we
could get a list of patches and new features people are planning to
Hey,
Beta 3 was supposed to be released on the 30th of November but got side
tracked because of the whole __toString() issue. Now it's resolved and
SimpleXML still works like a charm I'd like to aim for Beta 3 next week
(including the StudlyCaps standard adoption).
Can we aim for a definitive 9
Markus Fischer wrote:
Since every man and his cow already gave a vote, I'll do so too and
vote -1 for theCapsStyle in PHP itself. However, I think e.g. the
DOM extension should be left at what the W3C suggested (other
extension my need exceptions too).
I agree with M
On Thu, 4 Dec 2003, Andi Gutmans wrote:
> I think you misunderstood what I said. I said that I support underscore
> naming, but it should be allowed in extensions which follow a specific
> standard such as DOM (W3C), obviously Java connectivity (that's really not
> under our control anyway because
> From: Andi Gutmans [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 03, 2003 11:43 PM
> At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:
> >Markus Fischer wrote:
> > > [...]
> >> I like the initial argument brought up by Mr. Wendel, namely to
> >> easily differentiate bet
Andi Gutmans wrote:
At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:
Markus Fischer wrote:
> [...]
I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland
written
method calls.
- Markus (and his
I think you misunderstood what I said. I said that I support underscore
naming, but it should be allowed in extensions which follow a specific
standard such as DOM (W3C), obviously Java connectivity (that's really not
under our control anyway because it depends on how you write your Java code).
At 11:35 PM 12/3/2003 +0100, Michael Walter wrote:
Markus Fischer wrote:
> [...]
I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland written
method calls.
- Markus (and his cow)
How is this an adv
At 11:14 PM 12/3/2003 +0100, Georg Richter wrote:
I'm -1.
And for ext/mysqli which supports OO, studlyCaps would make life harder, to
migrate "old" php4 scripts to PHP5 and ext/mysqli.
How about an additional configure option --with-studly-caps (disabled by
default) and defining some additional al
-1
*Caps syntax is harder to read & use compared to the underscore based system,
which we already use. Having 2 separate naming conventions is confusing and
difficult and you end up with the code which will mix & match both of them
resulting in confusing and difficult to read code.
Ilia
--
P
On 2003/12/04, at 7:14, Georg Richter wrote:
How about an additional configure option --with-studly-caps (disabled
by
default) and defining some additional aliases?
When we ought to have it, it must be --withStudylyCaps as well :)
Moriyoshi
--
PHP Internals - PHP Runtime Development Mailing Lis
Markus Fischer wrote:
> [...]
I like the initial argument brought up by Mr. Wendel, namely to
easily differentiate between PHP method calls and userland written
method calls.
- Markus (and his cow)
How is this an advantage?
Cheers,
Michael
--
PHP Internals - PHP Runtime De
On Wed, Dec 03, 2003 at 11:23:05PM +0100, Derick Rethans wrote :
> Andi,
>
> I'm -1 too because I want PHP being consistently have _ in
> method/function names. (Another reason is to see the difference between
> core and user code as Ulf pointed out).
Since every man and his cow already
Sascha Schumann wrote:
-1 on embracing studlyCaps in the context of PHP itself.
(Note: studlyCaps originated with a OO language, namely
Smalltalk, but it is not pervasive in OO land. If you don't
believe me, just look at the STL. You won't find any
uglyCaps over there.)
George Schlossnagle wrote:
On the other hand, there are Common Lisp (foo-bar-baz), Python (mostly
foobarbaz) and Ruby (mostly foo_bar_baz).
To be pedantic, the Python style guide
(http://www.python.org/peps/pep-0008.html) specifies class names to be
StudlyCaps and method names to be either und
> 3rd using different naming conventions in procedural and oo code seems to be
> a pro from my point of view, too.
What is the perceived advantage here?
Do you type "->" and immediately forgot what follows that?
This really is no argument in the context of PHP (no implicit
bindin
Georg Richter wrote:
How about an additional configure option --with-studly-caps (disabled by
default) and defining some additional aliases?
Ouch... That would render code written from one place unusable on
another server..
Oliver
--
GB/E/IT d+ s+:+ a-- C++$ UL$ P L+++$ E- W++$ N- ?o ?K
Andi,
I'm -1 too because I want PHP being consistently have _ in
method/function names. (Another reason is to see the difference between
core and user code as Ulf pointed out).
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
On Dec 3, 2003, at 5:14 PM, Michael Walter wrote:
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
-1 on embracing studlyCaps in the context of PHP itself.
(Note: studlyCaps originated with a OO language, namely
Smalltalk, but it is not pervasive in OO land. If you don't
believe me, just look at the STL. You won't find any
uglyCaps over there.)
- Sascha
--
PHP Inter
I'm -1.
And for ext/mysqli which supports OO, studlyCaps would make life harder, to
migrate "old" php4 scripts to PHP5 and ext/mysqli.
How about an additional configure option --with-studly-caps (disabled by
default) and defining some additional aliases?
Georg
--
PHP Internals - PHP Runtime
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) had anything to do with _ rendering)
On Wed, 3 Dec 2003, Marcus Boerger wrote:
> 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).
That's bollocks. I put tha
On Thu, 4 Dec 2003, Moriyoshi Koizumi wrote:
> 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 di
+1 on studlyCaps
pierre
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
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)
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
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)
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
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
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
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
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/
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
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{
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
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, 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:
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.
> 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
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'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.
-
> 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
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
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
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
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]>
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
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
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
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
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
> > 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
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.
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
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".
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
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
> 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
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: 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]
>
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.
>
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
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
> 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
> 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
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
>
> 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
> >
>
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
> 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
> 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
> 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: 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
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
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
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:
> 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: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:
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 ;
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
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
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
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
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
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:
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
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
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
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
1 - 100 of 133 matches
Mail list logo
