Re: [PHP-DEV] PHP 5.0.3 Variable Bug or Something More?
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 and file a bug in our bugsystem, please. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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. This is exactly the same thing. It is a data firewall for PHP. You don't have to use it, but people want it and need it. I would think the difficulty would be in informing people that functionality like this is only the start of good security. Maybe a proper, official, howto on PHP security should be drawn up The phpsec group started a project to do just that: http://www.phpsec.org/ There are no silver bullets here. Also homogenic solutions are not what you want for security either. Basically what we can do is make the big nono's known and provide tools that as transparently as possible enhance security. If using filters requires people to jump through hoops there is little gain if any. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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_overloading.diff -- 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 Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 user classes? Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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/ GnuPG Key: 0xB85B5D69 / 27A7 2B14 09E4 98CD 6277 0E5B 6867 C514 B85B 5D69 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 they can add two objects. Use C++/Java if you want this... Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 people that they can add two objects. Use C++/Java if you want this... I couldn't agree more. I like PHP not because it is the most compact or flexible of all languages but because the syntax is quite simple. Try explaining someone who just learned PHP and doesn't know your code where to find the implementation of $c = $a + $b; as opposed to $c= $a->add($b); or $c = Complex::add($a, $b); Another little thought how confusion can easily happen with operator overloading: $b = $a + 42; works but $b = 42 + $a; doesn't, i.e. the overloaded addition isn't commutative. Just my 2 Rappen, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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: http://www.php.net/unsub.php
[suspicious - maybe spam] [PHP-DEV] input filtering Re: [PHP-DEV] PHP 5.1
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 they are necessary. This is exactly the same thing. It is a data firewall for PHP. You don't have to use it, but people want it and need it. After a little discussion on #php.pecl I would like to clarify my position. I think it makes absolute sense to have an input filter that implements a global security for PHP. However as this feature only makes sense with considerable knowhow in defining a sensible global (global in the sense that it may span multiple applications) security policy I see no reason why this needs to be in core versus it being in PECL. Especially since alot of people are worried about smart ass admins (especially mass hosters) who dont listen to developers enabling the thing just because it sounds like a good idea. This means that the functionality will be available to people who know (tm). At the same time this is not a complete solution as a global security policy is not going to be as finely grained as needed. So a set of easy to use tools to use inside your application is also necessary. Actually it should be clear to all that just as a firewall input filtering does not replace data validation, even if in some cases data validation with inplut filters in front my seem redundant. We seriously need a taint model that will ensure that people get some sort of reminder if they let unchecked data pass through. regards, Lukas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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, right? ;-) As I already asked in the past, I'm in favour to have them for intern usage only (understand used by extension). As we already for propoerties read or write. For those who do not know, you have no way to know that you in a ++, -- call. At least for ++,-- and friends. A typical usage could be data that fits in a defined range (ie date/time values). Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 figure what $i++ means now, in absence of any type delcarations. 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 $foo + 1, but 1 + $foo won't? Will + be non-commutative operation from now on? What with assign-ops - it would leak memory in this case? -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 it the same > way - it's pure syntax sugar. And it really ruins the readability > of the code - go figure what $i++ means now, in absence of any > type delcarations. (speaking only for internal needs) I think you are wrong here. Example: d = new date(2005,2,31); d->day++: You are out, no way to know where you are inside the read or write property(ies) functions. That said I agree that userland operators overloading is not a good idea. Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 data? Making the generic filter a backup that jumps in where no protection exists, rather than an 'ipso facto, will break stuff' kinda deal? It doesn't make a lot of sense from where I'm standing to have a generic security setup that _isn't_ default, but it really shouldn't break BC in any way. Just my 2 sheks, - Steph - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Derick Rethans" <[EMAIL PROTECTED]> Cc: "Ilia Alshanetsky" <[EMAIL PROTECTED]>; Sent: Thursday, February 03, 2005 2:51 AM Subject: Re: [PHP-DEV] PHP 5.1 > At 01:44 PM 2/2/2005 -0800, Rasmus Lerdorf wrote: > >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 this need > >will be available to them in PECL. > > It'd be great if we can all sync on one implementation. > I know it gets a bit hard with everyone pulling their way and having yet > another suggestion but I'm sure we can reach something everyone is happy with. > In any case, the main part of this project are the filters themselves ,and > that work shouldn't be replicated. > I must say that personally I probably would prefer a programmatic way of > filtering (as I mentioned it could be done at runtime), but I don't think > it would be terrible to have a paranoid mode that filters earlier. > So just to lay out my $0.02 it'd be nice to have something like: > filter_all(POST, FILTER_FOOBAR); > and > $foo = filter_input(POST, "foo", FILTER_NUM); > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 people that they can add two
> > objects. Use C++/Java if you want this...
>
> I couldn't agree more. I like PHP not because it is the most compact or
> flexible of all languages but because the syntax is quite simple.
>
> Try explaining someone who just learned PHP and doesn't know your code
> where to find the implementation of
> $c = $a + $b;
> as opposed to
> $c= $a->add($b);
> or
> $c = Complex::add($a, $b);
If $a is an object of a class, then they would both be in the class
definition. One is called "add", and the other is called "operator+". What's
the problem with that?
> Another little thought how confusion can easily happen with operator
> overloading: $b = $a + 42; works but $b = 42 + $a; doesn't, i.e. the
> overloaded addition isn't commutative.
It would if operator overloading was allowed on free functions (as it is in
C++). E..g:
function operator+(complex $a, complex $b)
{
return new complex($a.real + $b.real, $a.imag + $b.imag);
}
The binary operators are recommended to to free functions, for this reason,
in C++.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
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's assignment and hope you didn't miss reassignment on the way. TS>>It would if operator overloading was allowed on free functions (as it is in TS>>C++). E..g: You can't do it like in C++, because in C++ function signature includes argument types, and in PHP it does not. I.e., you can't write two operators - one for complex+int and one for complex+complex. In general, it's too much trouble for too little gain - except for select things like complex and matrices (and maybe two more things like this) I don't see any value in having, say, + overloaded. Using good old methods will never fail you. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 they can add two
> objects.
That's only confusing if you don't know that operator overloading is
possible. In C++, it's perfectly natural to be able to e.g. add values of
user-defined types. It also enables generic code, such as:
function some_calculation($num1, $num2)
{
$num1+=1;
$num2+=num1;
...
}
This would then work for any object (built-in type or user-defined type
(class)) having operator+= defined.
Why this would be confusing is beyond me... Could you enlighten me?
Specifically, do you find the following:
$result=$c1.multiply($c2).divide($c1.add($c2));
less "confusing" than:
$result=($c1 * $c2) / ($c1 + $c2);
?
>Use C++/Java if you want this...
Why would it be ok there, but not in PHP? It also exists in other scripting
languages, such as Python and Perl.
BTW, as another poster pointed out, it doesn't exist in Java, either, except
for the "+" exception for strings. I think omitting that is a case of
"throwing the baby out with the bath water". Yes, used incorrectly, operator
overloading can be confusing, but that's also the case for more or less any
language feature, and we don't ban them. It's no less confusing having the
member function "add()" perform subtraction, as it is to let the "+" do
that.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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? Over my smoking carcass! PHP 5 returns object handles, which lets you do _exactly_ the same thing, only without the obscurity. Nobody needs overloaded operators. Code should be readable, not cuddly-cute. - Stig -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
> 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, right? ;-)
>
> As I already asked in the past, I'm in favour to have them for
> intern usage only (understand used by extension).
Internal in what way? And why?
> As we already for
> propoerties read or write. For those who do not know, you have no
> way to know that you in a ++, -- call. At least for ++,-- and
> friends.
I'm not sure I understood the above, but if I understood it right, why would
that be?
class SomeClass
{
function operator++() // #1
{
return ++$this->value;
}
function operator($dummy) // #2 ***
{
return $value++;
}
var $value;
}
$object=new SomeClass();
++$object; // Calls #1
$object++; // Calls # 2
(***) This is how it's done in C++ (actually, a dummy int parameter), which
is a bit of a hack, to be able to specify both the pre- and
post-increment/decrement operators. #2 (and postfix "--") is the "odd" one,
since they are the only postfix operators among the operators.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 written the patch mainly for learning about PHP and the Zend Engine as a proof-of-concept and not as a thing I would like to propose so I was satisfied when it was running. By showing it to a few people I got some feedback about the way I've implemented it and learned how to do it better. Most of this input ended at my brain not in the patch so it's far from good, I still stress that I'm no C coder ;-) So all what's (not) there needs to be seen from that position. For being committed it would need some work. > $foo + 1, but 1 + $foo won't? Will + be non-commutative operation from now In case of operator overloading this would become true - not for simple types - when leaving the field of simple numbers an "addition operation" isn't allways communitative. Think on "adding" two strings - you would expect different results from "foo"+"bar" and "bar"+"foo". (Yes, I know that PHP has the concat operator . so this is just an example) > on? What with assign-ops - it would leak memory in this case? As said it's in proof-of-concept state. I last looked over it during the conference in Frankfurt and afair at least --enable-debug didn't report a leak ;-) Enough (if not even too much) for the moment, johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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, or we'd all be writing assembly code." :) Besides, it's not "just" syntactic sugar: See my other posts in this thread, but briefly, they enable "generic code" - code that may be used by both built-in and user-defined types, without knowing or caring which is which. That is indeed powerful, and most of the advances in later years in C++ has come in the area of generic programming (where templates are used for this, since types are checked at compile-time). > And it really ruins the readability of the code - go > figure what $i++ means now, in absence of any type delcarations. If it's sensibly implemented, it should increment $i (whatever that is), and return the previous value. This is no more confusing than "increment_and_return($i)", where you may also need to look at the function definition. I find the first version much clearer, though. > 2. The referenced patch raises doubts - why it allows to override / but > not %, for example? What with all other operators? I agree that if operator overloading was added, it should be available for all operators where it makes sense. > Why add would work as > $foo + 1, but 1 + $foo won't? Both would work if we allow operator overloading on free functions. But that may be too radical for some people, it seems. Just to drive the point home: Operator (and function) overloading is not an OO feature. However, it's often found in OO languages, and complements OO well. It's a different kind of polymorphism. > Will + be non-commutative operation from now on? There shoudn't be a need for that. We should try to avoid such surprises. > What with assign-ops - it would leak memory in this case? Why would it do that? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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 choice, more or less. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 the writer. The latter is syntax sugar. It is important, but not at the price of making code harder to read or language slower to work. TS>>Besides, it's not "just" syntactic sugar: See my other posts in this thread, TS>>but briefly, they enable "generic code" - code that may be used by both TS>>built-in and user-defined types, without knowing or caring which is which. I don't see how using $a + 1 is better than using $a->add(1) in this regard. TS>>That is indeed powerful, and most of the advances in later years in C++ has TS>>come in the area of generic programming (where templates are used for this, TS>>since types are checked at compile-time). C++ is typed, so you need to jump trhough various hoops to make it work in non-typed way, while preserving it's typedness benefits. PHP works differently - you don't have benefits and need no hoops. TS>>This is no more confusing than "increment_and_return($i)", where you may TS>>also need to look at the function definition. I find the first version much TS>>clearer, though. Well, I guess it's the matter of personal taste. For me, the second is the clear winner - you can name function after what it actually does and not hope that everybody knows ++ makes an iterator go to the next element. TS>>Both would work if we allow operator overloading on free functions. But that It can't be done without making PHP strict-typed - you coldn't really distinguish which function is to be called, and you couldn't distinguish between functions with same name. Even if you could - how many operator+'s you are willing to write? For all type combinations? Or what is supposed to happen if + called for type combination that you don't have an operator for? TS>>Operator (and function) overloading is not an OO feature. However, it's TS>>often found in OO languages, and complements OO well. It's a different kind TS>>of polymorphism. It's no kind of polymorphism at all. It just an infix form of writing a method instead of prefix form, with additional problem that it is confused with plain old arithmetics. I see no value at all in this except for "cool toy" value - which is not enough to add such a serious change in the language. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
> 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 mean "not statically typed". I've been through this discussion elsewhere - a variable will at any one time have a well-defined type (or unset), which you may overload on, so the language is definitely not typeless. An example of a typeless (or single type language, if you like) language is BCPL, where there was only one type, the machine word. As mentioned in another posting, operator overloading also exists in other dynamically typed languages, such as Python and Perl. > You'll have to trace all the program up to $a's assignment and hope you > didn't miss reassignment on the way. Yes, variables are dynamically typed, but when you call a function, you typically have an idea of what its type is. Otherwise, the "type hints" for PHP 5 would be pointless! By your argument. > TS>>It would if operator overloading was allowed on free functions (as it is in > TS>>C++). E..g: > > You can't do it like in C++, because in C++ function signature includes > argument types, and in PHP it does not. That's right, so we'd really need function overloading to be able to use the free function form, which I think is another good idea (function overloading). > I.e., you can't write two > operators - one for complex+int and one for complex+complex. In general, > it's too much trouble for too little gain Well, you're certainly entitled to your opinion, but others, including me, think it's worth it. > - except for select things like > complex and matrices (and maybe two more things like this) I don't see any > value in having, say, + overloaded. Using good old methods will never fail > you. Neither will assembly code. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 floating around for a > > while? > > Operator overloading in PHP? Over my smoking carcass! > > PHP 5 returns object handles, which lets you do _exactly_ the same thing, > only without the obscurity. You mean $a + $b? add($a, $b) is _not_ "exactly the same thing". > Nobody needs overloaded operators. Code should be readable, not > cuddly-cute. 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 what operator overloading is about). As I've pointed out in other postings in this thread, operator overloading is about much more than "just" "syntactic sugar". In C++, for example, it enables important things such as function objects (being able to pass an object to a function, for example, and have it behave as a function, enabling functional programming, as well). This is not possible (possibly without jumping through major hoops) in PHP. However, I see from this and other threads, that there's not much chance of evolution of PHP to support more "advanced" features (which are common in other scripting languages, as mentioned). It seems basic OO support is about the only thing the PHP community can handle when it comes to expressiveness in the language. Oh, well. Oh, and the comment about "Code should be readable, not cuddly-cute": Operator overloading is about being able to express your intent clearer in the code - leading to _more_ readable code than the corresponding function alternative (see my arithmetic example in another posting). It has nothing to do with cuteness, and everything to do with being to express your intent clearly in the code. But it seems the community isn't ready for this. Too bad. Maybe in PHP 10. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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. > > > > > > > > Java does not support operator overloading. > > > > > > So, that means PHP shouldn't get it either, right? ;-) > > > > As I already asked in the past, I'm in favour to have them for > > intern usage only (understand used by extension). > > Internal in what way? And why? Available for extensions only (means also not in user land), like the get/set get_properties for objects. > > As we already for > > propoerties read or write. For those who do not know, you have > > no way to know that you in a ++, -- call. At least for ++,-- and > > friends. > > I'm not sure I understood the above, but if I understood it right, > why would that be? For now you cannot know if are in a '++' or a '--'. The operations (I have to check that again :) are: $b->a++; gives tmp = a; tmp = tmp+1; b->a = tmp; In my example (a date object, day being 31), at this I do not know if one is assigning 32 to the property or if it's the result of incrementation (or decrementation from 1 to 0). Regards, --Pierre -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
>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 for PHP. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 making them neigh impossible to debug and require all sorts of hackery inside the language itself to support this functionality. Ilia Terje Slettebø wrote: 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, or we'd all be writing assembly code." :) Besides, it's not "just" syntactic sugar: See my other posts in this thread, but briefly, they enable "generic code" - code that may be used by both built-in and user-defined types, without knowing or caring which is which. That is indeed powerful, and most of the advances in later years in C++ has come in the area of generic programming (where templates are used for this, since types are checked at compile-time). And it really ruins the readability of the code - go figure what $i++ means now, in absence of any type delcarations. If it's sensibly implemented, it should increment $i (whatever that is), and return the previous value. This is no more confusing than "increment_and_return($i)", where you may also need to look at the function definition. I find the first version much clearer, though. 2. The referenced patch raises doubts - why it allows to override / but not %, for example? What with all other operators? I agree that if operator overloading was added, it should be available for all operators where it makes sense. Why add would work as $foo + 1, but 1 + $foo won't? Both would work if we allow operator overloading on free functions. But that may be too radical for some people, it seems. Just to drive the point home: Operator (and function) overloading is not an OO feature. However, it's often found in OO languages, and complements OO well. It's a different kind of polymorphism. Will + be non-commutative operation from now on? There shoudn't be a need for that. We should try to avoid such surprises. What with assign-ops - it would leak memory in this case? Why would it do that? Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
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, but still I find it hard to imagine why Perl (at least if we speak of Perl 4/5) would need one. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 what operator overloading is about). As I've pointed out in other postings in this thread, operator overloading is about much more than "just" "syntactic sugar". In C++, for example, it enables important things such as function objects (being able to pass an object to a function, for example, and have it behave as a function, enabling functional programming, as well). This is not possible (possibly without jumping through major hoops) in PHP. That's because functions are not first-class objects in PHP. You can do this same thing in straight C without operator overloading. While I'm happy (for you) that you like operator overloading, the view that it is inherently evil and leads to obtuse, magical code is not relegated to us PHP luddites. These ideas have all been discussed in depth long before you appeared on the scene to decry our lack of interest in 'evolving' the language to your liking. George -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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 $date->PreviousDay() and neither ++, nor --, nor manipulating properties directly :) -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
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 That's the whole point - in PHP there's no mechanism you could overload function based on the types of their parameters, neither statically nor dynamically. To add this thing would be a very major change and will open galactic-size can of worms (think "implicit conversions", "converting constructors", "multiple inheritance", etc.). And this would seriously complicate function call logic - which is very bad, because, unlike statically-typed language, we can not offload this complexity to one-time compile stage. TS>>Yes, variables are dynamically typed, but when you call a function, you TS>>typically have an idea of what its type is. Otherwise, the "type hints" for TS>>PHP 5 would be pointless! By your argument. Type hints check if the argument passed to function is of the right type. They don't make PHP call different functions on different argument types. TS>>That's right, so we'd really need function overloading to be able to use the TS>>free function form, which I think is another good idea (function TS>>overloading). See above. TS>>> - except for select things like TS>>> complex and matrices (and maybe two more things like this) I don't see any TS>>> value in having, say, + overloaded. Using good old methods will never fail TS>>> you. TS>> TS>>Neither will assembly code. What is with that assembly code that you keep mentioning it? Assembly code is entirely irrelevant to the discussion, since, as I already explained once, difference between assebmly code and higher-level programming languages in in complexity incapsulation, while difference between operator overloading and using method is purely syntactical - operator overloading can be translated one-to-one to method calls without exposing any complexity, while translating method call to assemly exposes a lot of complexity. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 bringing examples of how useful it is in C++ - which can be interesting to debate, but is entirely irrelevant to PHP, since PHP is different from C++ on many levels and tasks that are solved with operators in C++ often even not exist in PHP (like "smart pointers", etc.). I still fail to see how it can be really useful - in terms of making something that was very hard to do before easy to do now - beyond they syntax sugar value. TS>>things such as function objects (being able to pass an object to a function, TS>>for example, and have it behave as a function, enabling functional TS>>programming, as well). This is not possible (possibly without jumping TS>>through major hoops) in PHP. Surely it is. Via __call, for example, which is no worse than operator(). Yes, you could not write it the same syntax as C++ - so what? TS>>However, I see from this and other threads, that there's not much chance of TS>>evolution of PHP to support more "advanced" features (which are common in There's a lot of chance for PHP to evolve, but if you mean by it that any feature that you might like would be in without scrutiny - yes, there's little chance for that. TS>>other scripting languages, as mentioned). It seems basic OO support is about TS>>the only thing the PHP community can handle when it comes to expressiveness TS>>in the language. Oh, well. It means you probably won't see in PHP every feature that your favorite other language has. So what? Your favorite other language probably doesn't have all the features of PHP. The new features for PHP should be checked if they are good for PHP and can be implemented consistently and efficiently in PHP. -- Stanislav Malyshev, Zend Products Engineer [EMAIL PROTECTED] http://www.zend.com/ +972-3-6139665 ext.115 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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 to 0). > > nor manipulating properties directly :) I know you put a :) there, but if you really mean it then you should NOT be using PHP! Reason: PHP isn't about OO cosyness - it's about solving a Web problem. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] snprintf defined as ap_php_snprintf
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 be ap_php_snprintf. If we #undef snprintf (thus using glibc's snprintf), the problem is cleared up. In this segment of the diff between versions 1.178.2.9 and 1.178.2.8 of php.h, you'll see that tests for the existence of a system snprintf were removed. -#if !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) || PHP_BROKEN_SPRINTF || PHP_BROKEN_SNPRINTF || PHP_BROKEN_VSNPRINTF #include "snprintf.h" -#endif Is this a deliberate change? Is there some way to tell configure to use the system snprintf instead of the PHP version? Thanks, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snprintf defined as ap_php_snprintf
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. It turns out that in 4.3.10, > snprintf is #defined to be ap_php_snprintf. If we #undef snprintf > (thus using glibc's snprintf), the problem is cleared up. > > In this segment of the diff between versions 1.178.2.9 and 1.178.2.8 > of php.h, you'll see that tests for the existence of a system snprintf > were removed. > > -#if !defined(HAVE_SNPRINTF) || !defined(HAVE_VSNPRINTF) || > PHP_BROKEN_SPRINTF || PHP_BROKEN_SNPRINTF || PHP_BROKEN_VSNPRINTF > #include "snprintf.h" > -#endif > > 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 number formatting. To make your extension work, make sure to include main/snprintf.h. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] [patch] ReflectionProperty::getLinenumber
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[Class|
Function|Method]::get[Start|End]Line() Methods.
As you can see I extended the zend_property_info structure to hold the
linenumber. If an extension registers a property using zend_declare_property
it is assumed that the property was defined at line 0.
johannes
The patch is also available at
http://anonsvn.schlueters.de/svn/phpatches/HEAD/reflectionProperty_getLinenumber.diff
--
Johannes SchlÃter [EMAIL PROTECTED]
Mayflower GmbH / ThinkPHP Tel: 089 / 24 20 54 - 33
Sendlinger Str. 42aFax: 089 / 24 20 54 - 29
80331 MÃnchen http://www.mayflower.de
Index: Zend/zend_API.c
===
RCS file: /repository/ZendEngine2/zend_API.c,v
retrieving revision 1.269
diff -u -r1.269 zend_API.c
--- Zend/zend_API.c 2 Nov 2004 13:10:37 - 1.269
+++ Zend/zend_API.c 6 Dec 2004 23:21:46 -
@@ -1882,8 +1882,7 @@
return module->version;
}
-
-ZEND_API int zend_declare_property(zend_class_entry *ce, char *name, int name_length, zval *property, int access_type TSRMLS_DC)
+ZEND_API int zend_declare_property_ex(zend_class_entry *ce, char *name, int name_length, zval *property, int access_type, int line TSRMLS_DC)
{
zend_property_info property_info;
HashTable *target_symbol_table;
@@ -1945,12 +1944,18 @@
}
property_info.flags = access_type;
property_info.h = zend_get_hash_value(property_info.name, property_info.name_length+1);
+ property_info.line = line;
zend_hash_update(&ce->properties_info, name, name_length + 1, &property_info, sizeof(zend_property_info), NULL);
return SUCCESS;
}
+ZEND_API int zend_declare_property(zend_class_entry *ce, char *name, int name_length, zval *property, int access_type TSRMLS_DC)
+{
+ return zend_declare_property_ex(ce, name, name_length, property, access_type, 0 TSRMLS_CC);
+}
+
ZEND_API int zend_declare_property_null(zend_class_entry *ce, char *name, int name_length, int access_type TSRMLS_DC)
{
zval *property;
Index: Zend/zend_API.h
===
RCS file: /repository/ZendEngine2/zend_API.h,v
retrieving revision 1.192
diff -u -r1.192 zend_API.h
--- Zend/zend_API.h 4 Oct 2004 20:17:04 - 1.192
+++ Zend/zend_API.h 6 Dec 2004 23:21:48 -
@@ -187,6 +187,7 @@
ZEND_API char *zend_get_module_version(char *module_name);
ZEND_API int zend_get_module_started(char *module_name);
ZEND_API int zend_declare_property(zend_class_entry *ce, char *name, int name_length, zval *property, int access_type TSRMLS_DC);
+ZEND_API int zend_declare_property_ex(zend_class_entry *ce, char *name, int name_length, zval *property, int access_type, int line TSRMLS_DC);
ZEND_API int zend_declare_property_null(zend_class_entry *ce, char *name, int name_length, int access_type TSRMLS_DC);
ZEND_API int zend_declare_property_long(zend_class_entry *ce, char *name, int name_length, long value, int access_type TSRMLS_DC);
ZEND_API int zend_declare_property_string(zend_class_entry *ce, char *name, int name_length, char *value, int access_type TSRMLS_DC);
Index: Zend/zend_compile.c
===
RCS file: /repository/ZendEngine2/zend_compile.c,v
retrieving revision 1.601
diff -u -r1.601 zend_compile.c
--- Zend/zend_compile.c 6 Dec 2004 11:53:30 - 1.601
+++ Zend/zend_compile.c 6 Dec 2004 23:21:55 -
@@ -2714,7 +2714,7 @@
property->type = IS_NULL;
}
- zend_declare_property(CG(active_class_entry), var_name->u.constant.value.str.val, var_name->u.constant.value.str.len, property, access_type TSRMLS_CC);
+ zend_declare_property_ex(CG(active_class_entry), var_name->u.constant.value.str.val, var_name->u.constant.value.str.len, property, access_type, zend_get_compiled_lineno(TSRMLS_C) TSRMLS_CC);
efree(var_name->u.constant.value.str.val);
}
Index: Zend/zend_compile.h
===
RCS file: /repository/ZendEngine2/zend_compile.h,v
retrieving revision 1.297
diff -u -r1.297 zend_compile.h
--- Zend/zend_compile.h 27 Oct 2004 17:58:45 - 1.297
+++ Zend/zend_compile.h 6 Dec 2004 23:21:57 -
@@ -138,6 +138,7 @@
char *name;
int name_length;
ulong h;
+ int line;
} zend_property_info;
Index: Zend/zend_reflection_api.c
===
RCS file: /repository/ZendEngine2/zend_reflection_api.c,v
retrieving revision 1.140
diff -u -r1.140 zend_reflection_api.c
--- Zend/zend_reflection_api.c 24 Nov 2004 19:56:54 - 1.140
+++ Zend/zend_reflection_api.c 6 Dec 2004 23:22:04 -
@@ -3316,6 +3316,20 @@
zend_reflection_class_factory(ref->ce
RE: [PHP-DEV] snprintf defined as ap_php_snprintf
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 number formatting. To make your > > extension work, make sure to include main/snprintf.h. > > I'm afraid I might not have been clear. In 4.3.10, php.h includes > snprintf.h, which defines snprintf as ap_php_snprintf. Unfortunately, > ap_php_snprintf is failing, causing the module to crash. If I force it to > use glibc's snprintf, everything works fine. Unfortunately, ap_php_snprintf > isn't an option right now, and I'm wondering what is the cleanest way to > insure that the system snprintf is used. You can't do that actually. What fails in ap_php_snprintf? We need to fix that instead. (And always CC the mailinglist). regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 the writer. It depends on how you define "complexity". Are the following two lines equally complex to you: 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. > The > latter is syntax sugar. It is important, but not at the price of making > code harder to read If it makes the code harder to read, it's not much of "syntactic sugar", is it? I can't see why operator overloading should make it harder to read. The only thing I can think of is that, given that there's no type declarations in PHP, it may be hard to know, looking at a line, what the type of the variable is. However, in a properly written program, the actual type may not be that important. Take for example: $sum = $money1 + $money2; Whether or not the variables are built-ins or from a money/currency class, should matter little to your understanding of this code. > or language slower to work. Why would it become slower. As you say, the notation is essentially "syntactic sugar" for a function call, and should be equally fast. > TS>>Besides, it's not "just" syntactic sugar: See my other posts in this thread, > TS>>but briefly, they enable "generic code" - code that may be used by both > TS>>built-in and user-defined types, without knowing or caring which is which. > > I don't see how using $a + 1 is better than using $a->add(1) in this > regard. What if you want to add two variables? > TS>>That is indeed powerful, and most of the advances in later years in C++ has > TS>>come in the area of generic programming (where templates are used for this, > TS>>since types are checked at compile-time). > > C++ is typed Statically typed, yes. >, so you need to jump trhough various hoops to make it work in > non-typed way, while preserving it's typedness benefits. Yes, if you want to use C++ in a typeless/dynamically typed way, you need to use things like templates, or a variant type. However, since those are available, you get the benefits of something similar to type inference, and also static type checking. > PHP works differently - you don't have benefits and need no hoops. You don't have benefits of what? (Should "don't" have been omitted?) > TS>>This is no more confusing than "increment_and_return($i)", where you may > TS>>also need to look at the function definition. I find the first version much > TS>>clearer, though. > > Well, I guess it's the matter of personal taste. For me, the second is > the clear winner - you can name function after what it actually does and > not hope that everybody knows ++ makes an iterator go to the next element. Oh, well. Programming by guesswork is always hard. A point with programming languages is that once you've learned them, and their abstractions, it makes it easier for you to program. Operator overloading is no different. > TS>>Both would work if we allow operator overloading on free functions. But that > > It can't be done without making PHP strict-typed - you coldn't really > distinguish which function is to be called, and you couldn't distinguish > between functions with same name. Yes, you'd need function overloading (we already have type hints, which could be used for the overload resolution). > Even if you could - how many operator+'s > you are willing to write? For all type combinations? That depends on what you want. I can't see how this question is different from "How many member functions (like add()) are you willing to write?"? > Or what is supposed > to happen if + called for type combination that you don't have an operator > for? An error, like today. > TS>>Operator (and function) overloading is not an OO feature. However, it's > TS>>often found in OO languages, and complements OO well. It's a different kind > TS>>of polymorphism. > > It's no kind of polymorphism at all. Yes, overloading is a form of polymorphism. Depending on the type of the arguments, different functions are called. This is analogous to inheritance-based polymorphism (virtual functions). See http://research.microsoft.com/Users/luca/Papers/OnUnderstanding.pdf for a good treatment of the various kinds of polymorphisms there are (even if the article is rather mathematical/technical). > It just an infix form of writing a > method instead of prefix form, with additional problem that it is confused > with plain old arithmetics. I see no value at all in this except for "cool > toy" value - which is not enough to add such a serious change in the > language. I beg to differ. Operator overloading allows you to write what essentially are domain-s
Re: [PHP-DEV] PHP 5.1
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 code have > > the same complexity but look prettier to the eyes of the writer. > > It depends on how you define "complexity". Are the following two lines > equally complex to you: Let me be blunt as you;'e not giving up. We will not add it. Period, punt, punktum. This discussion is pointless - stop it! Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] how to make nasty code less nasty (obtaining sqlite db handle)
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 what I can
tell, determine the resource type to expect. Is there a nicer way of doing
this?
PHP_FUNCTION(my_PHP_function)
{
int id;
int dataLen;
int resourceType;
char * pData;
zval * zdb;
void * hDB;
void ** phDB;
/* Ensure we got the correct number of parameters */
if (ZEND_NUM_ARGS() != 2)
{
WRONG_PARAM_COUNT;
}
/* Retrieve the parameters */
if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
"rs",
&zdb, &pData, &dataLen) == FAILURE)
{
return;
}
/*
* Voodoo to retrieve the sqlite database handle from the resource.
* How do I validate that resourceType is reasonable?
*/
id = zdb->value.lval;
if ((phDB = zend_list_find(id, &resourceType)) == NULL)
{
return;
}
/*
* This is nasty too. We "know" that the first field in the private
* structure is the database handle. Just extract it.
*/
hDB = *phDB;
RETURN_STRING(my_C_function(hDB, pData), TRUE);
}
Thanks,
Derrell
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: referencing Superglobals with variable variables inside functions
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
> +++ Zend/zend_execute.c 31 Jan 2005 22:13:50 -
> @@ -1001,6 +1001,10 @@
> {
> switch (opline->op2.u.EA.type) {
> case ZEND_FETCH_LOCAL:
> + if (zend_hash_exists(CG(auto_globals),
> variable->value.str.val, variable->value.str.len + 1)) {
> + /* Dynamically resolved auto global */
> + return &EG(symbol_table);
> + }
> return EG(active_symbol_table);
> break;
> case ZEND_FETCH_GLOBAL:
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?
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 overloading. The question is why would it not be appropriate for PHP? Dynamic typing has been mentioned, and when I said that it exists in other dynamically typed languages, as well, I get the reply that "PHP is not language xxx". What kind of reply is that?! Ilia Alshanetsky suggested in a posting that the PHP community in general might not be ready for its safe introduction (i.e. they would typically misuse it). I hope it's not the case; after all, it's not such an "advanced" feature, when several mainstream languages has it. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 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.
Judging from much of the PHP code I've seen, I'm sorry to say that you may
be right... However, that doesn't mean _no_ users are ready for it.
> If anything it'll only over complicate
> applications making them neigh impossible to debug and require all sorts
> of hackery inside the language itself to support this functionality.
My experience isn't that misuse of language features is the biggest cause of
messy code, as inexperienced developers typically aren't aware of more
"advanced" features, and therefore don't use them. Rather, my experience is
that the biggest cause of messy code is simply lack of competence, beyond
knowing the language itself. Learning to be a good programmer takes many
years, regardless of language.
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 mean we should forbid
these features in the language!
Used properly, if anything, the features proposed in my postings (like
overloading, and optional type checking) would allow people to _simplify_
their code. C++ code is typically simpler than Java code, for this reason.
Take this example (incrementing an element in a map):
C++:
++my_map[key];
Java:
if ( !my_map.containsKey( key ) )
my_map.put( key, new Integer( 1 ) );
else
{
Integer count = ( Integer )my_map.get( key ) );
int icount = count.IntValue();
my_map.put( key, new Integer( ++icount ) );
}
Operator overloading isn't the only thing playing a part, here (the ability
to treat built-in and user-defined types the same way is another major
factor), but it's a major factor.
Now, for this particular example, PHP actually has a similarly succinct
form, but that's only because the PHP array _is_ a map, so you have a
built-in type with operators:
++$my_map[$key];
The advantage of operator overloading is similar to the advantage of
symbolic notation in mathematics: It allows you to succinctly express your
intent, and it's also international.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1
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 > To: internals@lists.php.net > Subject: Re: [PHP-DEV] PHP 5.1 > > >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 overloading. The question is why > would it not be appropriate for PHP? Dynamic typing has been mentioned, > and > when I said that it exists in other dynamically typed languages, as well, > I > get the reply that "PHP is not language xxx". What kind of reply is that?! > Ilia Alshanetsky suggested in a posting that the PHP community in general > might not be ready for its safe introduction (i.e. they would typically > misuse it). I hope it's not the case; after all, it's not such an > "advanced" > feature, when several mainstream languages has it. > > Regards, > > Terje > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] snprintf defined as ap_php_snprintf
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 aware number formatting. To make your > > > extension work, make sure to include main/snprintf.h. > > > > I'm afraid I might not have been clear. In 4.3.10, php.h includes > > snprintf.h, which defines snprintf as ap_php_snprintf. Unfortunately, > > ap_php_snprintf is failing, causing the module to crash. If I force it > to > > use glibc's snprintf, everything works fine. Unfortunately, > ap_php_snprintf > > isn't an option right now, and I'm wondering what is the cleanest way to > > insure that the system snprintf is used. > > You can't do that actually. Is it necessary to override the system snprintf? This is a potential trap for the unwary programmer. It took us a fair amount of digging to discover that this was happening. I haven't found any documentation that warns that snprintf might behave differently then one is used to. > What fails in ap_php_snprintf? We need to > fix that instead. I'm afraid I've not been able to pin-point the problem more then that. The target is an embedded system with limited memory, so debugging can be a challenge at times. Looking at my original message, I realize that I forgot to mention that the crash occurs only in mod_php, not the stand alone excutable of php. > (And always CC the mailinglist). Ack, sorry about that. Thanks, Jeff -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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, and I'm looking forward to reading it.
>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 what operator overloading is about). As I've
>> pointed out
>> in other postings in this thread, operator overloading is about much
>> more
>> than "just" "syntactic sugar". In C++, for example, it enables
>> important
>> things such as function objects (being able to pass an object to a
>> function,
>> for example, and have it behave as a function, enabling functional
>> programming, as well). This is not possible (possibly without jumping
>> through major hoops) in PHP.
>That's because functions are not first-class objects in PHP. You can
>do this same thing in straight C without operator overloading. While
>I'm happy (for you) that you like operator overloading, the view that
>it is inherently evil and leads to obtuse, magical code is not
>relegated to us PHP luddites. These ideas have all been discussed in
>depth long before you appeared on the scene to decry our lack of
>interest in 'evolving' the language to your liking.
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 decried wasn't this thing in particular, and I'm
relatively new to the PHP online community, but from the responses I got,
felt something of a complacency ("The language is good enough as it is. Who
needs advanced features. They may be misused. Etc."), and I guess I reacted
to that, because I find it rather different in the C++ mailing lists and
newsgroups, where there's often lively discussions about the evolution of
the language. So it was more a perceived lack of willingness to consider, or
reconsider, proposals, and give reasonable arguments in return. Arguments
where given, I replied to them, and then it typically went nowhere from
there. Anyway, I'd be interested in any evolution, and by all means, PHP 5
has come a long way. But it probably wouldn't have been like this, had there
not been "early adopters", and people pushing for things like better OO
support.
Let me also mentioned that I _have_ found cool things in PHP, especially
things making it easier for web-programming, such as things like variable
functions, where you may dispatch to a function based on a string, for
example a GET parameter. This can lead to rather elegant code. Likewise, the
OO support is quite good, now.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 to do using (static or non-static) functions: 3) $result = Complex::divide(Complex::multiply($c1, $c2), Complex::add($c1, $c2)); Greg -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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, from what I've seen of
it,
also looks very good, and I'm looking forward to reading it.
Thanks. I've heard good things about Andi, Stig and Derick's book as
well.
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 what operator overloading is about). As I've
pointed out
in other postings in this thread, operator overloading is about much
more
than "just" "syntactic sugar". In C++, for example, it enables
important
things such as function objects (being able to pass an object to a
function,
for example, and have it behave as a function, enabling functional
programming, as well). This is not possible (possibly without jumping
through major hoops) in PHP.
That's because functions are not first-class objects in PHP. You can
do this same thing in straight C without operator overloading. While
I'm happy (for you) that you like operator overloading, the view that
it is inherently evil and leads to obtuse, magical code is not
relegated to us PHP luddites. These ideas have all been discussed in
depth long before you appeared on the scene to decry our lack of
interest in 'evolving' the language to your liking.
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 decried wasn't this thing in particular, and I'm
relatively new to the PHP online community, but from the responses I
got,
felt something of a complacency ("The language is good enough as it
is. Who
needs advanced features. They may be misused. Etc."), and I guess I
reacted
to that, because I find it rather different in the C++ mailing lists
and
newsgroups, where there's often lively discussions about the evolution
of
the language.
The real problem is that there's a constant influx of (usually)
well-meaning people like yourself who come to the lists to propose
ideas which have been discussed in depth numerous times before and
which have been discarded (for better or worse, my personal opinion is
for better in this case). 'Prone to misuse' and 'tends to result in
unmaintainable code' are (in my exposure) two pretty common reasons
that people dislike operator overloading.
At any rate, it's been discussed before and shelved, long before you
came on the scene. Even though the topic is new for you in this venue,
it's old for many other people, and it gets annoying to rehash the same
topics every couple months when someone new joins the list. The
discussions are all in the archives though, if you want to see the
less-reactionary roots of the rejections.
George
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] snprintf defined as ap_php_snprintf
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_php_snprintf() one as that has an >> > > extra modified %F for non-locale aware number formatting. To make your >> > > extension work, make sure to include main/snprintf.h. >> > >> > I'm afraid I might not have been clear. In 4.3.10, php.h includes >> > snprintf.h, which defines snprintf as ap_php_snprintf. Unfortunately, >> > ap_php_snprintf is failing, causing the module to crash. If I force it >> to >> > use glibc's snprintf, everything works fine. Unfortunately, >> ap_php_snprintf >> > isn't an option right now, and I'm wondering what is the cleanest way to >> > insure that the system snprintf is used. >> >> You can't do that actually. > Is it necessary to override the system snprintf? This is a potential trap > for the unwary programmer. It took us a fair amount of digging to discover > that this was happening. I haven't found any documentation that warns that > snprintf might behave differently then one is used to. >> What fails in ap_php_snprintf? We need to >> fix that instead. > I'm afraid I've not been able to pin-point the problem more then that. The > target is an embedded system with limited memory, so debugging can be a > challenge at times. Looking at my original message, I realize that I forgot > to mention that the crash occurs only in mod_php, not the stand alone > excutable of php. >> (And always CC the mailinglist). > Ack, sorry about that. > Thanks, Well the problem is thatlots of systems are provide c libs that have very big memory problems that result in hige security risks or are simply not conforming to ISOc99 standatd which we require. One of the biggest problems is [v][s|f][n]printf() since we are focused on outputting something. -- Best regards, Marcusmailto:[EMAIL PROTECTED] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 mean we should forbid these features in the language! You're wrong, that's exactly one of the things PHP does: Keep the language simple by limiting the amount of (syntactic) magic. their code. C++ code is typically simpler than Java code, for this reason. Can we please stop comparing PHP to C++? They have completely different design philosophies (and so have Python, Perl and Ruby). symbolic notation in mathematics: It allows you to succinctly express your intent, and it's also international. PHP is _not_ about expressing things succinctly but comprehensibly, i.e. with simple language constructs like method calls. Regards, - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
> 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 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
>
> That's the whole point - in PHP there's no mechanism you could overload
> function based on the types of their parameters, neither statically nor
> dynamically. To add this thing would be a very major change and will open
> galactic-size can of worms (think "implicit conversions", "converting
> constructors", "multiple inheritance", etc.).
No, you don't have to go that far. For starters, one could allow function
(and possibly operator) overloading, based on type hints. The following is
legal PHP5:
function something(SomeClass $value) { ... }
We could make the signature (currently only the name) extend to include the
parameters, as well, so we could allow the following, without errors about
duplicate definition:
function something(AnotherClass $value) { ... }
That's it. That's all you need for function overloading. You can safely keep
the lid on that can of worms of yours. :) If we were to extend this, I'm
sure we'd find a way to deal with any "worms".
> And this would seriously complicate function call logic
It would increase the complexity somewhat, since you have to perform
overload resolution. However, how much on an impact this would have on
execution speed remains to be seen.
> - which is very bad, because, unlike
> statically-typed language, we can not offload this complexity to one-time
> compile stage.
Right.
> TS>>Yes, variables are dynamically typed, but when you call a function,
you
> TS>>typically have an idea of what its type is. Otherwise, the "type
hints" for
> TS>>PHP 5 would be pointless! By your argument.
>
> Type hints check if the argument passed to function is of the right type.
> They don't make PHP call different functions on different argument types.
I know. My point was that, as we have type hints, we have a way to
differentiate functions, since they may now both have variable types, and
number of parameters.
> TS>>> - except for select things like
> TS>>> complex and matrices (and maybe two more things like this) I don't
see any
> TS>>> value in having, say, + overloaded. Using good old methods will
never fail
> TS>>> you.
> TS>>
> TS>>Neither will assembly code.
>
> What is with that assembly code that you keep mentioning it?
It was a reaction to the oft-mentioned argument that essentially says: "We
don't need more advanced features." I got that feeling when you said "Using
good old methods will never fail you.". However, I may have misread you. If
taken to the limit, you don't need more than ones and zeroes to program, but
it sure makes it easier to have higher levels of abstraction. Anyway, it
seems we agree on that.
> Assembly code
> is entirely irrelevant to the discussion, since, as I already explained
> once, difference between assebmly code and higher-level programming
> languages in in complexity incapsulation, while difference between
> operator overloading and using method is purely syntactical - operator
> overloading can be translated one-to-one to method calls without exposing
> any complexity, while translating method call to assemly exposes a lot of
> complexity.
I've replied to this in the reply to that posting, so I won't go into it
here.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] For help
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.h files for this tutorial that actually work? On Wed, 2 Feb 2005 00:19:55 +0800, taft <[EMAIL PROTECTED]> wrote: How can I write a module for PHP? Any ABC information? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- How about an article/HowTo/Tutorial that you can follow that provides a working example that you can build that actually works. Without a working example to follow it's difficult to see what is really required and the debugging of partial code isn't pretty. -- Dale -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 against operator overloading. The question is why would it not be appropriate for PHP? Dynamic typing has been mentioned, and when I said that it exists in other dynamically typed languages, as well, I get the reply that "PHP is not language xxx". What kind of reply is that?! Quote from your mail: "Why would it be ok there, but not in PHP? It also exists in other scripting languages, such as Python and Perl." Please explain me why it's okay for you to use the other-languages-card but not for me? :) Please, end this thread already and face the fact that this feature will not get into PHP 5.1. --Jani -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] PHP 5.1
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 first. David -Original Message- From: Terje Slettebø [mailto:[EMAIL PROTECTED] Sent: Thursday, February 03, 2005 11:18 PM To: internals@lists.php.net Subject: Re: [PHP-DEV] PHP 5.1 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 overloading. The question is why would it not be appropriate for PHP? Dynamic typing has been mentioned, and when I said that it exists in other dynamically typed languages, as well, I get the reply that "PHP is not language xxx". What kind of reply is that?! Ilia Alshanetsky suggested in a posting that the PHP community in general might not be ready for its safe introduction (i.e. they would typically misuse it). I hope it's not the case; after all, it's not such an "advanced" feature, when several mainstream languages has it. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> 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 think you did not succeed in proving this point. You keep bringing > examples of how useful it is in C++ - which can be interesting to debate, > but is entirely irrelevant to PHP, since PHP is different from C++ on many > levels and tasks that are solved with operators in C++ often even not > exist in PHP (like "smart pointers", etc.). I still fail to see how it can > be really useful - in terms of making something that was very hard to do > before easy to do now - beyond they syntax sugar value. It's a little hard to bring examples of PHP usage of it, since it doesn't exist there, and therefore we have no experience with it. However, I saw someone post a patch about it, enabling overloaded operators in PHP. > TS>>things such as function objects (being able to pass an object to a function, > TS>>for example, and have it behave as a function, enabling functional > TS>>programming, as well). This is not possible (possibly without jumping > TS>>through major hoops) in PHP. > > Surely it is. Via __call, for example, which is no worse than operator(). > Yes, you could not write it the same syntax as C++ - so what? An advantage of function objects in C++ is that they can be used where functions are expected. Nevertheless, there are some features that can be used to get something similar, such as create_function(): > TS>>However, I see from this and other threads, that there's not much chance of > TS>>evolution of PHP to support more "advanced" features (which are common in > > There's a lot of chance for PHP to evolve, but if you mean by it that any > feature that you might like would be in without scrutiny - yes, there's > little chance for that. By all means, I'm all for scrutiny. :) That's why I bring it up, to possibly stimulate some discussion about it, and, yes, scrutiny. I may learn at least as much from this as anyone else. Simply put, I'd like to know what the arguments for and against are, so that, yes, they may be scrutinised. > TS>>other scripting languages, as mentioned). It seems basic OO support is about > TS>>the only thing the PHP community can handle when it comes to expressiveness > TS>>in the language. Oh, well. > > It means you probably won't see in PHP every feature that your favorite > other language has. So what? Your favorite other language probably doesn't > have all the features of PHP. The new features for PHP should be checked > if they are good for PHP and can be implemented consistently and > efficiently in PHP. True. I see what I wrote above was rather harsh. I guess I in a way hoped that someone would tell me I'm wrong. :) And that the PHP community _is_ interested in improvements in the language (any improvements, these are just some possibilities), and that possibly what I suggest is not what is found to be most interesting, but feature xyz may be, or library x. That would have been fine. I'm here to learn, too. So, ok, I acknowledge that the community _is_ interested in improvements in the language, and therefore take back the paragraph you quote above (and any statements like it). Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
>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.c++ for C++). > 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 to 0). > > > > nor manipulating properties directly :) > > I know you put a :) there, but if you really mean it then you should NOT > be using PHP! Reason: PHP isn't about OO cosyness - it's about solving a > Web problem. Hm, from several postings, I've detected something of a - I don't quite know how to say it in English - resentment against OO on PHP lists and newsgroups. Why is this? Unfamiliarity with it, or what? It typically gets expressed as derogatory expressions like "cosyness" or "cuteness", as a "quick and dirty" attempt to discredit something without any proper argument. Now, whether or not you're accessing properties has nothing in particular with the language you use; it's a design issue. Oh, and it has nothing to do with "cosyness" and everything to do with program robustness, correctness, encapsulation, decoupling of interface from implementation, and other time-honoured software development principles (which are independent of any particular "paradigm", such as OO). Most software development experts aren't "religious" about the issue of accessor functions. If your class is basically just a value container, without any class invariants to maintain, then accessing properties directly may be a reasonable way to do it. In the case of a date object, it's a really bad idea to be able to access the properties directly, because, as it says in the quote above, you may e.g. increment the day beyond the end of the month, setting it to a negative value, etc. In short, it's an error-prone and bad design. Since you think it's a good idea to _have_ public properties for date objects, I'd like to hear your reasons for it. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 have >> > the same complexity but look prettier to the eyes of the writer. >> >> It depends on how you define "complexity". Are the following two lines >> equally complex to you: >Let me be blunt as you;'e not giving up. We will not add it. Period, >punt, punktum. This discussion is pointless - stop it! Apparently it is, but not because I've got convincing arguments in return. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 have in the language/library. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: referencing Superglobals with variable variables inside functions
> 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->op2.u.EA.type is set at compile time. In the case of $_GET, the compiler knows that _GET is a superglobal so it sets it to ZEND_FETCH_GLOBAL In the case of $$g (where $g was previously set to '_GET') the compiler doesn't know what $g is yet (since it's only really set at runtime), so it has no reason to set it to ZEND_FETCH_GLOBAL. Could it be intelligent enough to see that in: $g = '_GET'; $$g is always going to be '_GET' and therefor $$g and $_GET are really the same thing? Perhaps. But what about: $g = '_'; $g .= 'G'; $g .= 'E'; $g .= 'T'; Or the enigmatic: $g = '_TRG'; $g = str_rot13($g); Building the run-time intelligence into a compiler would be well do I really need to spell that one out? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 functions use
prefix,
> > only.
>
> Um, you're wrong. Infix is quite easy to do using (static or
> non-static) functions:
>
> 3) $result = Complex::divide(Complex::multiply($c1, $c2),
Complex::add($c1, $c2));
Let me rewrite your expression as an abstract expression:
result = op(op(c1, c2), op(c1, c2))
Here, "op" is the function name ("add", etc.). As you can see, your
expression is still one using prefix operators ("op arg1 arg2"), rather than
infix ("arg1 op arg2"). I'm afraid your correction is incorrect.
Your example is the same as 1), above, using static functions.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 variables and > > variable functions comes to mind), but that doesn't mean we should forbid > > these features in the language! > > You're wrong We should forbid variable variables and variable functions? That's what I talked about when we said "that doesn't mean we should forbid these features in the language". >, that's exactly one of the things PHP does: Keep the > language simple by limiting the amount of (syntactic) magic. Keeping a language simple is not necessary a good thing in itself. C is an example of a relatively simple language, for example. When we make applications, there's a certain amount of "essential complexity", and that complexity has to go somewhere. When we have OO support, and libraries, we can delegate much of that complexity to the language/library, making our programs simpler. If the complexity is not in the language or library, it'll be in the programs. I'd rather have the complexity in the language or library, so that the programs can be simpler. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: referencing Superglobals with variable variables inside functions
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 the way it is handled now? The thing i don't get is, why the superglobals behave differently than "normal" global variables at all. Ok, you have explained the technical reasons, but that's not what i mean. For me as a php user (developing in php), the only difference should be, that i don't have to use the global keyword. Everything else seems like a bug or design flaw to me. Sure i can work around the restriction somehow, but this should not be the final solution. Sorry to bother you further. ;) Michael Sara Golemon wrote: 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->op2.u.EA.type is set at compile time. In the case of $_GET, the compiler knows that _GET is a superglobal so it sets it to ZEND_FETCH_GLOBAL In the case of $$g (where $g was previously set to '_GET') the compiler doesn't know what $g is yet (since it's only really set at runtime), so it has no reason to set it to ZEND_FETCH_GLOBAL. Could it be intelligent enough to see that in: $g = '_GET'; $$g is always going to be '_GET' and therefor $$g and $_GET are really the same thing? Perhaps. But what about: $g = '_'; $g .= 'G'; $g .= 'E'; $g .= 'T'; Or the enigmatic: $g = '_TRG'; $g = str_rot13($g); Building the run-time intelligence into a compiler would be well do I really need to spell that one out? -Sara -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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, such as Python and Perl. > >> > >> PHP is not Perl or Python or . > > > > That's not an argument against operator overloading. The question is why > > would it not be appropriate for PHP? Dynamic typing has been mentioned, and > > when I said that it exists in other dynamically typed languages, as well, I > > get the reply that "PHP is not language xxx". What kind of reply is that?! > > Quote from your mail: > > "Why would it be ok there, but not in PHP? It also exists in other scripting > languages, such as Python and Perl." > > Please explain me why it's okay for you to use the other-languages-card > but not for me? :) Ok. The argument went something like this: I asked (although that was originally in another thread) about the possibility of getting operator overloading in PHP, and I presented reasons for why this may be useful. Then someone replied that PHP is dynamically typed, so it "doesn't fit the language". I countered with that there are other languages that are also dynamically typed, but where they do have operator overloading. Now, if the "doesn't fit the language" argument should stick, one could need to either: 1) Explain why it's a bad idea in these other languages, as well, or: 2) Explain how PHP is different, and why it doesn't fit PHP, unlike these languages. Now, have I got any answers to this? No! All I've got (from your posting, anyway) is "PHP is not language xxx". And? How does it change the argument? In what way is it different, so that operator overloading would not fit with PHP? I've got some answers in this thread, and I'll also search the archive for the rest, but "PHP is not language xxx" is a meaningless "answer". My use of the other languages was to show that other languages find it useful. Your use of other languages... well, it only says that PHP are not them, which doesn't really say anything beyond the obvious. I'm sorry, but our two arguments can't be compared. > Please, end this thread already and face the fact that this feature > will not get into PHP 5.1. I have no illusions of it going into PHP 5.1... This wouldn't be appropriate for a point release, for one thing. I have also very little belief of it ever getting into PHP, judging from the discussion. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: referencing Superglobals with variable variables inside functions
> 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 access $$a, you're getting 'HTTP_GET_VARS' from the LOCAL symbol
table (where it exists as a reference of the global symtable version).
> 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 the way it is handled
> now? The thing i don't get is, why the superglobals behave differently
> than "normal" global variables at all.
In a word: efficiency.
There's an expression: "Fast, Clean, Cheap: Pick Two".
The current implementation is Fast and Cheap, but as this thread has
highlighted, it's not entirely clean.
> Ok, you have explained the technical reasons, but that's not what i mean.
> For me as a php user (developing in php), the only difference should be,
> that i don't have to use the global keyword. Everything else seems like a
> bug or design flaw to me.
>
You won't hear a lot of argument from me. I just care less that it is the
way it is.
-Sara
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
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 you can still build complete PHP apps without using any OO concepts. So the seemingly resentful attitudes should probably be viewed as one of "lets do our best to keep this as simple as possible while retaining the power it is intended to provide". On Feb 3, 2005, at 4:36 PM, Terje Slettebø wrote: Hm, from several postings, I've detected something of a - I don't quite know how to say it in English - resentment against OO on PHP lists and newsgroups. Why is this? Unfamiliarity with it, or what? It typically gets expressed as derogatory expressions like "cosyness" or "cuteness", as a "quick and dirty" attempt to discredit something without any proper argument. -- Darrell Brogdon http://darrell.brogdon.net -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 it is because of stubbborness, perhaps because you're not the first who had asked, perhaps a totally different reason. Atm it is a one against many discussion and you seem to be the only one eager to keep it going. Simply stop it now. You made your arguments. If many many ppl ask for that feature for a longer period of time, they'll reconsider implementing it. Atm you simply look like a C++ programmer, who can't realize that PHP has different goals than C++, that you can't adapt and that you won't stop argueing something obviously noone wants to consider anyway. Sorry to be that straight. ;) Michael -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Re: referencing Superglobals with variable variables inside functions
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 List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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: 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_overloading.diff -- 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 Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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 practise. It confuses the hell out of people that they can add two objects. Use C++/Java if you want this... BTW, in general Java also decided that it sucks. Except for + which is a bit magical it also requires to use verbose methods. This is a big time/life saver because operator overloading is very confusing and obscure. I think it's only nice in theory and not in real world usage. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
>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 decried wasn't this thing in particular, and I'm
>> relatively new to the PHP online community, but from the responses I
>> got,
>> felt something of a complacency ("The language is good enough as it
>> is. Who
>> needs advanced features. They may be misused. Etc."), and I guess I
>> reacted
>> to that, because I find it rather different in the C++ mailing lists
>> and
>> newsgroups, where there's often lively discussions about the evolution
>> of the language.
>The real problem is that there's a constant influx of (usually)
>well-meaning people like yourself who come to the lists to propose
>ideas which have been discussed in depth numerous times before and
>which have been discarded (for better or worse, my personal opinion is
>for better in this case).
I figured that could be the case, which is also, in my first postings, I
said that if this had been discussed before, I'd appreciate pointers to it,
because I hadn't found it in the archive. However, I got hardly any response
to that, which is why I kept asking about things that may have been asked
and answered a zillion times.
>At any rate, it's been discussed before and shelved, long before you
>came on the scene. Even though the topic is new for you in this venue,
>it's old for many other people, and it gets annoying to rehash the same
>topics every couple months when someone new joins the list. The
>discussions are all in the archives though, if you want to see the
>less-reactionary roots of the rejections.
I've searched for "overloading" on the archive for this list, as well as
others and the newsgroups, but, as I said above, found very little about it.
However, now that I know it's there, I'll make a new attempt.
Thanks for your reply.
Regards,
Terje
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to make nasty code less nasty (obtaining sqlite db handle)
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
crashing if someone passes the wrong type of resource in. If you're
thinking of distributing your extension, we could add a more official
API for you to use, although that doesn't exist in older versions of
the extension, etc. etc.
Some time back, I proposed a framework (and even a patch IIRC) that
allowed this kind of thing at run-time; despite "we the extension
developers" liking the idea, there was some negative feedback from
andi/zeev so it never went further. Search the php-dev archives for
my name and "interfaces" for more on that if you're interesting in
this seeing light in PHP 5.2.
--Wez.
On Thu, 03 Feb 2005 17:03:45 -0500, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> 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 what I can
> tell, determine the resource type to expect. Is there a nicer way of doing
> this?
>
> PHP_FUNCTION(my_PHP_function)
> {
> int id;
> int dataLen;
> int resourceType;
> char * pData;
> zval * zdb;
> void * hDB;
> void ** phDB;
>
> /* Ensure we got the correct number of parameters */
> if (ZEND_NUM_ARGS() != 2)
> {
> WRONG_PARAM_COUNT;
> }
>
> /* Retrieve the parameters */
> if (zend_parse_parameters(ZEND_NUM_ARGS() TSRMLS_CC,
> "rs",
> &zdb, &pData, &dataLen) == FAILURE)
> {
> return;
> }
>
> /*
> * Voodoo to retrieve the sqlite database handle from the resource.
> * How do I validate that resourceType is reasonable?
> */
> id = zdb->value.lval;
> if ((phDB = zend_list_find(id, &resourceType)) == NULL)
> {
> return;
> }
>
> /*
> * This is nasty too. We "know" that the first field in the private
> * structure is the database handle. Just extract it.
> */
> hDB = *phDB;
>
> RETURN_STRING(my_C_function(hDB, pData), TRUE);
> }
>
> Thanks,
>
> Derrell
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] For help
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 information is missing and you can't make it work. You would have benefitted more from attending the 3 hour tutorial in person, where I was able to answer questions from the attendees and talk more about the topic than it was possible to transcribe. > Does anyone have the ares.c and php_ares.h files for this tutorial that > actually work? I used to. But they've gone missing. I miss them. I want to rebuild them, but have no time. I don't like your tone (particular from the mail you sent to me personally), so perhaps you should take a step back and think about the fact that PHP is a volunteer project, and that while everyone would love documentation for the internals, the people that know it are generally too busy with real life to sit down and write it. --Wez. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
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 too long, too many theoretical arguments when clearly this won't happen. Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1 - operator overloading
+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 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 too long, too many > theoretical arguments when clearly this won't happen. > > Andi > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: referencing Superglobals with variable variables inside functions
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/2005 +0100, Michael Virnstein wrote:
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
> +++ Zend/zend_execute.c 31 Jan 2005 22:13:50 -
> @@ -1001,6 +1001,10 @@
> {
> switch (opline->op2.u.EA.type) {
> case ZEND_FETCH_LOCAL:
> + if (zend_hash_exists(CG(auto_globals),
> variable->value.str.val, variable->value.str.len + 1)) {
> + /* Dynamically resolved auto global */
> + return &EG(symbol_table);
> + }
> return EG(active_symbol_table);
> break;
> case ZEND_FETCH_GLOBAL:
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?
Michael
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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, making the language completely case-sensitive, > etc, etc. > > 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 first. > > > > David > > > > > >> -Original Message- > >> From: Terje Slettebø [mailto:[EMAIL PROTECTED] > >> Sent: Thursday, February 03, 2005 11:18 PM > >> To: internals@lists.php.net > >> Subject: Re: [PHP-DEV] PHP 5.1 > >> > >>> 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 overloading. The question is why > >> would it not be appropriate for PHP? Dynamic typing has been mentioned, > >> and > >> when I said that it exists in other dynamically typed languages, as well, > >> I > >> get the reply that "PHP is not language xxx". What kind of reply is that?! > >> Ilia Alshanetsky suggested in a posting that the PHP community in general > >> might not be ready for its safe introduction (i.e. they would typically > >> misuse it). I hope it's not the case; after all, it's not such an > >> "advanced" > >> feature, when several mainstream languages has it. > >> > >> Regards, > >> > >> Terje > >> > >> -- > >> PHP Internals - PHP Runtime Development Mailing List > >> To unsubscribe, visit: http://www.php.net/unsub.php > >> > > > > > > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
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: >> Yeah, and don't forget goto, > register_globals, making the language completely case-sensitive, >> etc, etc. >> >> Just guess if any of that list will happen..ever? :) -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP-DEV] [PATCH] Bug# 27633 - Wrong translation in ASCII mode
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 ends up with '\r\r\n' line endings. This patch fixes that problem. I am not trying to be obstinate or make any enemies, just please just hear me out. I for one use PHP for batch scripting in an enterprise production environment. It works extremely well in this context. It's numerous extensions and other features provide a very robust, cross platform environment comparable to Perl without the bloat. I can hack together entire process flows very quickly and with better efficiency than using something like bash. Not mention that a simple PHP/iODBC install, and a couple kb of base code, provides an open source ETL platform that IMO is more flexible and able than most commercial ETL packages. But regardless of what I happen to be doing I have to be able to rely on the integrity of the data. I understand that the root of the wierdness associated with this bug is caused by the remote server munging the data and not PHP. But it is on the client to properly handle ASCII translation for FTP transfers. So if I am on a windows box and I specify that I want an ASCII transfer then I have to assume that it is being done correctly and my resulting file will have '\r\n' line endings. If I can't that rates as a critical bug in my book. I know I am new here and therefore my posts are probably ignored by the majority of the key players on this list. I am also not a very experienced C coder and I expect to get some flack for it when I put my code out there for public review. But rather than whine and send hate mail because nobody will fix it for me, I took the time to fix it and test it the best I can. All I am asking that someone with commit access take the time to review the patch and either commit it so that the rest of the user community can benefit from it or tell me in no uncertain terms what I am doing wrong that makes it unacceptable so I can work on it. The more input I can get from the internals gods the better my code will be and the better I will understand the internals to the best language ever conceived. And who knows maybe I will be a major contributor to PHP50. Isn't that what the open source community is about? I have it coming now don't I. :/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] how to make nasty code less nasty (obtaining sqlite db handle)
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 works, so that's fine, although there is a risk of > crashing if someone passes the wrong type of resource in. If you're > thinking of distributing your extension, we could add a more official > API for you to use, although that doesn't exist in older versions of > the extension, etc. etc. Thanks, Wez. My extension will likely never be used other than with locally-written code. My biggest concern is making use of the incestual knowledge of the private php_sqlite_db structure and that the database handle is the first field in it. That structure may change in the future. My use of this is as a function used in a query -- sqlite_create_function() is used to allow a call to a php function which passes the database handle to the extension function. Prior to today, my extension had its own private database handle that it initialized on the MINIT function, but I was causing a deadlock by calling this function from within a query in PHP which called the extension which tried to issue additional queries using my private database handle in the extension. Passing in the php-derived handle is the only way of eliminating that deadlock. I wonder whether I'm really alone in wanting access to a database handle for extensions. It would seem appropriate to provide access to the C-level database handle given a PHP resources. That would eliminate the need to base an extenion on insestual knowledge of the database-specific extension. Thanks again, Derrell -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] PHP 5.1
> > 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 this > > need will be available to them in PECL. > > Yes, there should be an extension that implements the filter functions - > but the normal data should still be available like it is in PHP 4.3 and > PHP 5.0. Adding an ext for those filters is a good thing, mangling > request data isn't (see the magic_quotes_gpc mess). > > Derick I agree very much with you on this. If PHP coders who are no admins on the server themselves have to start worrying about a default filter, that means they will have to filter all input because the default filter could be or might become something they don't want to see. And in that case, there's no use for a default for them anymore, they simply have to manually filter everything, just so they can get to their raw data. This whole default setting adds an uncertainty which will add a lot of lines of code. Please don't make the magic_quotes_gpc mistake again, because in my humble opinion, that was the worst thing that ever happened to PHP. Ron -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [Operators overloading] PHP 5.1
>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 typically don't fit that criteria >which is why you can still build complete PHP apps without using any OO >concepts. Yes, the gentle learning curve of PHP, and that you don't have to use OO is a good thing. >So the seemingly resentful attitudes should probably be >viewed as one of "lets do our best to keep this as simple as possible >while retaining the power it is intended to provide". Ok. Regards, Terje -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
