On Wed, 2 Feb 2005, Chris Cowan wrote:
> I've ran across some strangeness which I can't figure out. When I run
> the following code I get a Seg Fault / Bus Error in my apache log
> (SegFault on Linux and Bus Error on Mac OS X).
Make a short reproducing script, not relying on external resources an
Nick Loeve wrote:
Gareth Ardron wrote:
Rasmus Lerdorf wrote:
TCP/IP Firewalls break all sorts of applications as well until either
the application is modified to poke a hole in the firewall itself via
upnp, or you reconfigure the firewall. This makes firewalls
annoying, but they are necessary.
Andi Gutmans wrote:
> Comments/Flames/Praises to this list :)
Just curious: Have you considered adding the operator overloading
patch [1] by Johannes Schlüter that has been floating around for a
while?
Greetings,
Sebastian
--
[1] http://anonsvn.schlueters.de/svn/phpatches/HEAD/operator_ove
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> Andi Gutmans wrote:
> > Comments/Flames/Praises to this list :)
>
> Just curious: Have you considered adding the operator overloading
> patch [1] by Johannes Schlüter that has been floating around for a
> while?
This adds operator overloading to
Derick Rethans wrote:
> This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
--
[1]
http://anonsvn.schlueters.de/svn/phpatches/HEAD/operator_overloading_example.php
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
Gnu
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > This adds operator overloading to user classes?
>
> Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of people that
Derick Rethans wrote:
> Use C++/Java if you want this.
Java does not support operator overloading.
--
Sebastian Bergmann http://www.sebastian-bergmann.de/
GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69
--
PHP Internals - PHP Runtime Development
Derick Rethans wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
Derick Rethans wrote:
This adds operator overloading to user classes?
Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
practise. It confuses the hell out of peo
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > Use C++/Java if you want this.
>
> Java does not support operator overloading.
So, that means PHP shouldn't get it either, right? ;-)
Derick
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit:
Lukas Smith wrote:
Nick Loeve wrote:
Gareth Ardron wrote:
Rasmus Lerdorf wrote:
TCP/IP Firewalls break all sorts of applications as well until
either the application is modified to poke a hole in the firewall
itself via upnp, or you reconfigure the firewall. This makes
firewalls annoying, but t
On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
[EMAIL PROTECTED] (Derick Rethans) wrote:
> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > Use C++/Java if you want this.
> >
> > Java does not support operator overloading.
>
> So, that means PHP shouldn't get it either,
SB>> patch [1] by Johannes Schl?ter that has been floating around for a
SB>> while?
1. I personally don't think operator overloading is a good idea. It
doesn't add you anything you couldn't do without it the same way - it's
pure syntax sugar. And it really ruins the readability of the code - go
On Thu, 3 Feb 2005 13:00:13 +0200 (IST)
[EMAIL PROTECTED] (Stanislav Malyshev) wrote:
> SB>> patch [1] by Johannes Schl?ter that has been floating around
> SB>for a> while?
>
> 1. I personally don't think operator overloading is a good idea.
> It doesn't add you anything you couldn't do without i
Quiet voice from the peanut gallery:
If (IF) there were to be some generic filter behaviour, wouldn't it make
sense to give the existing filtering-type functions some intelligence about
whether that generic filter was enabled or not, and ensure that those
functions were always fed raw superglobals
> Derick Rethans wrote:
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> >>Derick Rethans wrote:
> >>>This adds operator overloading to user classes?
> >> Yes, have a look at Johannes' Complex example [1].
> >
> > Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> > pract
TS>>If $a is an object of a class, then they would both be in the class
TS>>definition. One is called "add", and the other is called "operator+". What's
TS>>the problem with that?
The problem is that you can't really know what $a is - PHP is typeless.
You'll have to trace all the program up to $a
> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Derick Rethans wrote:
> > > This adds operator overloading to user classes?
> >
> > Yes, have a look at Johannes' Complex example [1].
>
> Okay, mega Yuck then. Although it looks cool, I consider it as a bad
> practise. It confuses the hell out
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> Andi Gutmans wrote:
> > Comments/Flames/Praises to this list :)
>
> Just curious: Have you considered adding the operator overloading
> patch [1] by Johannes Schlüter that has been floating around for a
> while?
Operator overloading in PHP? Ove
> On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
> [EMAIL PROTECTED] (Derick Rethans) wrote:
>
> > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> >
> > > Derick Rethans wrote:
> > > > Use C++/Java if you want this.
> > >
> > > Java does not support operator overloading.
> >
> > So, that means PHP should
Hi,
Not wanting to discuss the pros and cons of operator overloading in PHP a
few notes about the implementation:
Stanislav Malyshev wrote:
> 2. The referenced patch raises doubts - why it allows to override / but
> not %, for example? What with all other operators? Why add would work as
I've wr
> SB>> patch [1] by Johannes Schl?ter that has been floating around for a
> SB>> while?
>
> 1. I personally don't think operator overloading is a good idea. It
> doesn't add you anything you couldn't do without it the same way - it's
> pure syntax sugar.
As someone said, "Syntactic sugar matters,
TS>>(***) This is how it's done in C++ (actually, a dummy int parameter), which
TS>>is a bit of a hack, to be able to specify both the pre- and
In C++, functions differ by argument. In PHP, they don't.
Not to say I view that C++ hack as a kludge which is accepted only because
there's no other ch
TS>>As someone said, "Syntactic sugar matters, or we'd all be writing assembly
TS>>code." :)
Someone was wrong. There are syntax constructs that allow to reduce
complexity of the code, an
On Thu, 3 Feb 2005, Terje Slettebø wrote:
Why would it be ok there, but not in PHP? It also exists in other scripting
languages, such as Python and Perl.
PHP is not Perl or Python or .
--Jani
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/
> TS>>If $a is an object of a class, then they would both be in the class
> TS>>definition. One is called "add", and the other is called "operator+".
What's
> TS>>the problem with that?
>
> The problem is that you can't really know what $a is - PHP is typeless.
When you say "typeless", i think you
> From: "Stig S. Bakken" <[EMAIL PROTECTED]>
>
> On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
>
> > Andi Gutmans wrote:
> > > Comments/Flames/Praises to this list :)
> >
> > Just curious: Have you considered adding the operator overloading
> > patch [1] by Johannes Schlüter that has been floatin
On Thu, 3 Feb 2005 18:12:44 +0100
[EMAIL PROTECTED] (Terje Slettebø) wrote:
> > On Thu, 3 Feb 2005 11:47:13 +0100 (CET)
> > [EMAIL PROTECTED] (Derick Rethans) wrote:
> >
> > > On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> > >
> > > > Derick Rethans wrote:
> > > > > Use C++/Java if you want this.
>From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>(***) This is how it's done in C++ (actually, a dummy int parameter),
which
> TS>>is a bit of a hack, to be able to specify both the pre- and
>
> In C++, functions differ by argument. In PHP, they don't.
Yes, but a different way might be used
C++ is not PHP and the sooner you realize this the better it will be.
Adding operator overloading will add yet another layer of "magic" that
will confuse users, who for the most part have demonstrated that they
are not ready for such features. If anything it'll only over complicate
applications
JT>>> Why would it be ok there, but not in PHP? It also exists in other
JT>>scripting > languages, such as Python and Perl.
BTW, I don't remember anything useful done with operator overloading on
Perl. I must say I wrote a lot of Perl when nothing like Perl 6 existed,
so I may be somewhat behind
On Feb 3, 2005, at 1:58 PM, Terje Slettebø wrote:
Hm, I'm surprised by this response from someone who's name I recognise
as an
active PHP contributor. The answer strikes me as either arrogant and/or
ignorant (note: I'm not saying you are that, but that's how the reply
comes
across, given what wha
PJ>>$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;
PJ>>
PJ>>In my example (a date object, day being 31), at this I do not know
PJ>>if one is assigning 32 to the property or if it's the result of
PJ>>incrementation (or decrementation from 1 to 0).
That's why one should use $date->NextDay() and $d
TS>>When you say "typeless", i think you mean "not statically typed". I've been
Not only, but in this case it is the main trait I meant.
TS>>through this discussion elsewhere - a variable will at any one time have a
TS>>well-defined type (or unset), which you may overload on, so the language is
TS>>across, given what what operator overloading is about). As I've pointed out
TS>>in other postings in this thread, operator overloading is about much more
TS>>than "just" "syntactic sugar". In C++, for example, it enables important
I think you did not succeed in proving this point. You keep bri
On Thu, 3 Feb 2005, Stanislav Malyshev wrote:
> PJ>>$b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp;
> PJ>>
> PJ>>In my example (a date object, day being 31), at this I do not know
> PJ>>if one is assigning 32 to the property or if it's the result of
> PJ>>incrementation (or decrementation from 1
Hello,
We recently upgraded a system from PHP 4.3.4 to 4.3.10, and tripped
over a problem with snprintf. One of our PHP extension modules
started failing, causing Apache to exit with code 0177. Investigation
showed the culprit to be snprintf. It turns out that in 4.3.10,
snprintf is #defined to
On Thu, 3 Feb 2005, Jeff Olhoeft wrote:
> Hello,
>
> We recently upgraded a system from PHP 4.3.4 to 4.3.10, and tripped
> over a problem with snprintf. One of our PHP extension modules
> started failing, causing Apache to exit with code 0177. Investigation
> showed the culprit to be snprintf. I
Hi,
here's a patch which is lying around on my disk for quite a while: It adds a
ReflectionProperty::getLinenumber()-Method to find the Linenumber where a
property was defined. I wrote it while working on a little code-browser
thing. This method corresponds to the already existing Reflection[Cl
On Thu, 3 Feb 2005, Jeff Olhoeft wrote:
> > > Is this a deliberate change? Is there some way to tell configure to
> > > use the system snprintf instead of the PHP version?
> >
> > You should always been using the ap_php_snprintf() one as that has an
> > extra modified %F for non-locale aware numbe
> TS>>As someone said, "Syntactic sugar matters, or we'd all be writing
assembly
> TS>>code." :)
>
> Someone was wrong. There are syntax constructs that allow to reduce
> complexity of the code, and there are constructs that make the code have
> the same complexity but look prettier to the eyes of
On Thu, 3 Feb 2005, [iso-8859-1] Terje Slettebø wrote:
> > TS>>As someone said, "Syntactic sugar matters, or we'd all be
> > TS>>writing assembly code." :)
> >
> > Someone was wrong. There are syntax constructs that allow to reduce
> > complexity of the code, and there are constructs that make the
I've written an extension which needs to accept a Resource which is an SQLite
database handle, and call a C function which will be using that db handle to
issue queries. What I've done works, but is kinda nasty because there doesn't
appear to be a clean way to obtain that database handle nor, from
Sara Golemon wrote:
> Index: Zend/zend_execute.c
> ===
> RCS file: /repository/ZendEngine2/zend_execute.c,v
> retrieving revision 1.692
> diff -u -r1.692 zend_execute.c
> --- Zend/zend_execute.c 22 Jan 2005 02:29:18 - 1.692
>
>From: "Jani Taskinen" <[EMAIL PROTECTED]>
> On Thu, 3 Feb 2005, Terje Slettebø wrote:
>
> > Why would it be ok there, but not in PHP? It also exists in other
scripting
> > languages, such as Python and Perl.
>
> PHP is not Perl or Python or .
That's not an argument against operator overload
> From: "Jani Taskinen" <[EMAIL PROTECTED]>
>
> C++ is not PHP and the sooner you realize this the better it will be.
I do realise it. However, I don't accept that as an argument against things
like operator overloading, which is found in scripting languages comparable
to PHP.
> Adding operator o
No offense, but before even thinking about operator overloading support,
really useful and crucial stuff like namespaces or Unicode support should be
tackled first.
David
> -Original Message-
> From: Terje Slettebø [mailto:[EMAIL PROTECTED]
> Sent: Thursday, February 03, 2005 11:18 PM
>
On Thu, 3 Feb 2005, Derick Rethans wrote:
> > > > Is this a deliberate change? Is there some way to tell configure to
> > > > use the system snprintf instead of the PHP version?
> > >
> > > You should always been using the ap_php_snprintf() one as that has an
> > > extra modified %F for non-locale
>From: "George Schlossnagle" <[EMAIL PROTECTED]>
By the way, I have your book ("Advanced PHP Programming"), which I found
very good. :) I've also recently got Andi Gutmans, Stig S. Bakken and Derick
Rethans book, "PHP 5 Power Programming", which, from what I've seen of it,
also looks very good, an
Terje Slettebø wrote:
1) $result=$c1.multiply($c2).divide($c1.add($c2));
2) $result=($c1 * $c2) / ($c1 + $c2);
They sure aren't to me. Moreover, they are not the same: operator
overloading enable you to use infix notation, whereas functions use prefix,
only.
Um, you're wrong. Infix is quite easy t
On Feb 3, 2005, at 5:51 PM, Terje Slettebø wrote:
From: "George Schlossnagle" <[EMAIL PROTECTED]>
By the way, I have your book ("Advanced PHP Programming"), which I
found
very good. :) I've also recently got Andi Gutmans, Stig S. Bakken and
Derick
Rethans book, "PHP 5 Power Programming", which, f
Hello Jeff,
Thursday, February 3, 2005, 11:18:40 PM, you wrote:
> On Thu, 3 Feb 2005, Derick Rethans wrote:
>> > > > Is this a deliberate change? Is there some way to tell configure to
>> > > > use the system snprintf instead of the PHP version?
>> > >
>> > > You should always been using the ap_
Terje Slettebø wrote:
Those who are experienced enough to "shoot themselves in the foot", but not
experienced enough to aim properly, :) might, however, obfuscate code with
"misuse" of more "advanced" language constructs (variable variables and
variable functions comes to mind), but that doesn't me
> From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>When you say "typeless", i think you mean "not statically typed".
>
> Not only, but in this case it is the main trait I meant.
...Because PHP has types, so I felt it was a misnomer to call it "typeless".
> TS>>through this discussion elsewhe
On Feb 02, 2005, at 16:53, Nicolas Bérard Nault wrote:
I think http://www.php.net/~wez/extending-php.pdf might help you.
Nice looking on the surface but, using it as a tutorial isn't good
because too much information is missing and you can't make it work.
Does anyone have the ares.c and php_ares.
On Thu, 3 Feb 2005, Terje Slettebø wrote:
From: "Jani Taskinen" <[EMAIL PROTECTED]>
On Thu, 3 Feb 2005, Terje Slettebø wrote:
Why would it be ok there, but not in PHP? It also exists in other
scripting
languages, such as Python and Perl.
PHP is not Perl or Python or .
That's not an argument a
Yeah, and don't forget goto,
Just guess if any of that list will happen..ever? :)
--Jani
On Thu, 3 Feb 2005, David Zülke wrote:
No offense, but before even thinking about operator overloading support,
really useful and crucial stuff like namespaces or Unicode support should be
tackled
> From: "Stanislav Malyshev" <[EMAIL PROTECTED]>
> TS>>across, given what what operator overloading is about). As I've
pointed out
> TS>>in other postings in this thread, operator overloading is about much
more
> TS>>than "just" "syntactic sugar". In C++, for example, it enables
important
>
> I th
>From: "Derick Rethans" <[EMAIL PROTECTED]>
Oh, hello. I recognise your name as one of the other authors of the book
"PHP 5 Power Programming", which I've recently got, and which looks very
good. It seems like all the "big guns" are on this list. :) (similar to
comp.lang.c++.moderated and comp.std
>From: "Derick Rethans" <[EMAIL PROTECTED]>
>> > TS>>As someone said, "Syntactic sugar matters, or we'd all be
>> > TS>>writing assembly code." :)
>> >
>> > Someone was wrong. There are syntax constructs that allow to reduce
>> > complexity of the code, and there are constructs that make the code
>From: "David Zülke" <[EMAIL PROTECTED]>
>No offense, but before even thinking about operator overloading support,
>really useful and crucial stuff like namespaces or Unicode support should
be
>tackled first.
None taken. :) Part of the reason for posting was to find out what people
would like to
> i must admit, that i don't know very much about the zend engine and the
> php core in general, but if "opline->op2.u.EA.type" "knows" if the
> variable is a local one, a global one or a static one, why hasn't it the
> value of ZEND_FETCH_GLOBAL for superglobals in the first place?
>
opline->op
>From: "Greg Beaver" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > 1) $result=$c1.multiply($c2).divide($c1.add($c2));
> >
> > 2) $result=($c1 * $c2) / ($c1 + $c2);
> >
> > They sure aren't to me. Moreover, they are not the same: operator
> > overloading enable you to use infix notation, whereas
>From: "Christian Schneider" <[EMAIL PROTECTED]>
> Terje Slettebø wrote:
> > Those who are experienced enough to "shoot themselves in the foot", but
not
> > experienced enough to aim properly, :) might, however, obfuscate code
with
> > "misuse" of more "advanced" language constructs (variable vari
ok, i see. But why does it work with variables that are set as global,
e.g. the $HTTP_*_VARS:
this works inside a function. is it because of the global keyword? If
so, why can't there be a "magic" "global $_GET, $_POST, $_SESSION ..."
set in every function, for every superglobal, instead of th
>From: "Jani Taskinen" <[EMAIL PROTECTED]>
> On Thu, 3 Feb 2005, Terje Slettebø wrote:
>
> >> From: "Jani Taskinen" <[EMAIL PROTECTED]>
> >
> >> On Thu, 3 Feb 2005, Terje Slettebø wrote:
> >>
> >>> Why would it be ok there, but not in PHP? It also exists in other
> > scripting
> >>> languages, suc
> ok, i see. But why does it work with variables that are set as global,
> e.g. the $HTTP_*_VARS:
>
> function test() {
> global $HTTP_GET_VARS;
> $a = 'HTTP_GET_VARS';
> var_dump($$a);
> }
> test();
> ?>
>
global $foo;
is the equivalent of:
$foo = &$GLOBALS['foo'];
So when you acces
I don't think its really a resentment (for the most part) against OO in
PHP even if it seems that way. One of the stated goals of PHP is to
have a low learning curve and this is something it does very well. I'm
sure you can agree that OO concepts typically don't fit that criteria
which is why
Terje Slettebø wrote:
I have also very little belief of it ever getting into PHP, judging from the
discussion.
Perhaps it will in PHP 12.0, perhaps never. Point is, that noone is
willing to give any reasons, because they all seem to agree, that at the
current point, they don't want it in. Perhaps
Sara Golemon wrote:
You won't hear a lot of argument from me. I just care less that it is the
way it is.
-Sara
:p. Ok, probably there will be some redesign when PHP 6 is on it's way,
perhaps not. :) Anyway, thanks for your time. ;)
Michael
--
PHP Internals - PHP Runtime Development Mailing Li
No. I am very much against operator overloading.
It leads to confusion and I can tell you that from a lot of C++ experience
debugging very large applications. The code looks sexy and it's horrible to
debug and understand what's happening.
Andi
At 10:59 AM 2/3/2005 +0100, Sebastian Bergmann wrote
At 11:23 AM 2/3/2005 +0100, Derick Rethans wrote:
On Thu, 3 Feb 2005, Sebastian Bergmann wrote:
> Derick Rethans wrote:
> > This adds operator overloading to user classes?
>
> Yes, have a look at Johannes' Complex example [1].
Okay, mega Yuck then. Although it looks cool, I consider it as a bad
pr
>From: "George Schlossnagle" <[EMAIL PROTECTED]>
>> Yes, I know that operator overloading, as well as statically
>> typed/dynamically typed, type checking, etc. are hotly debated topics,
>> and
>> that can be healthy, at least as long as there are reasonable
>> arguments for
>> either side. What I
There is no official way to do this kind of thing between arbitrary extensions.
When extensions that are written to share this information, they
typically export an XXX_API function that you can link against to
fetch the data.
What you've done works, so that's fine, although there is a risk of
cra
On Thu, 3 Feb 2005 18:05:58 -0500, D. Walsh <[EMAIL PROTECTED]> wrote:
>
> On Feb 02, 2005, at 16:53, Nicolas Bérard Nault wrote:
>
> > I think http://www.php.net/~wez/extending-php.pdf might help you.
>
> Nice looking on the surface but, using it as a tutorial isn't good
> because too much info
Guys,
This thread is cluttering the list.
This won't be implemented, we discussed it in the past and already reached
that decision, pretty much all of the PHP dev team agree so I suggest to
drop it and let's focus on stuff which will go into PHP...
Sorry to be so abrupt but this thread is getting
+1.
Nothing to see here, move along.
On Thu, 03 Feb 2005 18:01:37 -0800, Andi Gutmans <[EMAIL PROTECTED]> wrote:
> Guys,
>
> This thread is cluttering the list.
> This won't be implemented, we discussed it in the past and already reached
> that decision, pretty much all of the PHP dev team agree
Superglobals are compiled into global fetches. However, we didn't want to
and don't want to slow down the average fetch by checking if it's a
superglobal first (i.e. variable variable). This also includes $this which
is evaluted at compile-time.
I think this is quite fair.
Andi
At 11:12 PM 2/3/
Y'mean you were just teasing about goto? ;)
- Original Message -
From: "Jani Taskinen" <[EMAIL PROTECTED]>
To: "David Zülke" <[EMAIL PROTECTED]>
Cc:
Sent: Friday, February 04, 2005 1:11 AM
Subject: RE: [PHP-DEV] PHP 5.1
>
> Yeah, and don't forget goto, register_globals, ma
SH
Your weekly summary will be long enough as it is :)
"Steph" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> Y'mean you were just teasing about goto? ;)
>
>
> - Original Message -
> From: "Jani Taskinen" <[EMAIL PROTECTED]>
> Cc:
>>
Can someone *please* review and commit this patch.
http://www.binam.net/bug-27633.patch
Scope: PHP4 & PHP5 on windows
Overview: Some ftp servers send a '\r' before every '\n' when
transferring in ASCII mode. If the file being retrieved has windows
flavor line endings '\r\n', the resulting file end
Wez Furlong <[EMAIL PROTECTED]> writes:
> There is no official way to do this kind of thing between arbitrary
> extensions. When extensions that are written to share this information,
> they typically export an XXX_API function that you can link against to fetch
> the data.
>
> What you've done w
> > You guys can write your own implementation and put it in PECL alongside
> > the one I am putting in there and we can decide if any of them should be
> > bundled by default. Perhaps none of them should, but like it or not,
> > people want to filter at this level and the extension to satisfy thi
>From: "Darrell Brogdon" <[EMAIL PROTECTED]>
>I don't think its really a resentment (for the most part) against OO in
>PHP even if it seems that way. One of the stated goals of PHP is to
>have a low learning curve and this is something it does very well. I'm
>sure you can agree that OO concepts
83 matches
Mail list logo
