Re: [PHP-DEV] RFC: Automatic Property Initialization
Hi, big +1 from my side. Would love to see this functionality in 5.6. Thanks for the proposal, Gordon. Cheers, Toby -- Helping people to create high quality web apps http://qafoo.com Tobias Schlitthttp://schlitt.infoGPG Key: 0xC462BC14 signature.asc Description: OpenPGP digital signature
Re: [PHP-DEV] Type hinting/casting request for vote
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/07/2009 02:52 AM, Ilia Alshanetsky wrote: > Last week or so there was a fairly detailed discussion on the internals > list regarding type hinting based on my original patch. Since then the > patch has been revised to address the major concerns that were > identified (breakage of binary compatibility) as well extended with > additional functionality (object hint, type casting, reflection support, > etc...). > > The final patch is available here: http://ilia.ws/patch/type_hint_53_v2.txt > The test suit is available here: http://ia.gd/patch/type_hint_tests.tar.bz2 > > I would like to ask all developers to voice their opinions of whether it > makes sense to add this to 5.3 or to throw it away (either one is fine > btw). To keep the process simple & flamewar free, please restrict > yourself to +/- (1/0), next week monday I'll run a tally of the votes > and based on the result we can determine how to proceed further. +1 (5.4/6.0 and "object") - -- Tobias Schlitt tob...@schlitt.info GPG Key: 0xC462BC14 a passion for php http://schlitt.info/opensource Member of the eZ Components project http://components.ez.no -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpT6CEACgkQ5bO3TcRivBSHDACgu9ymI+3eDhyZozd+cn9f+cBi GIcAoLRK13NOZaSlQuKyMxl9Zu8TW16r =CCc0 -END PGP SIGNATURE- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] SplHeap->key()
Hi, On 11/19/2008 11:38 AM David Coallier wrote: >> I noticed that SplHeap returns the current element count of the heap >> from key(). I think it should return count - 1 to reflect 0 indexing. >> key won't be called outside of an iterator, so this makes sense. > I'd say this is a bug as well, would you mind opening a bug and > assigning it to me please? Done. Cheers, Toby -- Tobias Schlitt - Zend Certification Member GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Member of the eZ components project http://components.ez.no -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SplHeap->key()
Hi! I noticed that SplHeap returns the current element count of the heap from key(). I think it should return count - 1 to reflect 0 indexing. key won't be called outside of an iterator, so this makes sense. Regards, Toby -- Tobias Schlitt - Zend Certification Member GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Member of the eZ components project http://components.ez.no -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: jakob
On 12/18/2006 03:05 PM Jakob Westhoff wrote: > Contribute to PEAR project Image_3D. I confirm this. -- Tobias Schlitt - Zend Certification Member GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Member of the eZ components project http://components.ez.no -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Tiny pathinfo() patch
On 07/15/2006 12:35 PM Marcus Boerger wrote: > Hello Tobias, > looks good after the update. Can you provide a patch for HEAD too? > also please provide patches with "cvs di -upd". Done. Find the patches here: http://schlitt.info/misc/pathinfo-HEAD.patch http://schlitt.info/misc/pathinfo-5_2.patch Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Tiny pathinfo() patch
On 07/14/2006 10:09 PM Christian Schneider wrote:
> Tobias Schlitt wrote:
>> using string manipulation, I now patched pathinfo() to provide the
>> filename without extension per default with key "filename".
>>
>> Find the patch here: http://schlitt.info/misc/pathinfo.patch
> If the patch is considered then I would propose to also return the key
> "filename" if the filename does not have a suffix. The current code
> seems to only return it if it can find a '.' in the filename.
>
> I.e. change
> if (p) {
> idx = p - ret;
> add_assoc_stringl(tmp, "filename", ret, idx, 1);
> }
>
> to
> idx = p ? (p - ret) : ret_len;
> add_assoc_stringl(tmp, "filename", ret, idx, 1);
> or something like that.
Valid point. I updated the patch.
Have a nice weekend!
Toby
--
Tobias Schlitt - Zend Certified Engineer GPG Key: 0xC462BC14
a passion for phphttp://www.schlitt.info
Like to say "thank you"?- http://pear.php.net/wishlist.php/toby
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Tiny pathinfo() patch
Hi all! It occured several times in the past weeks, where I needed the filename without extension as well as the file extension extracted from a pathname. Since first calling pathinfo() and then basename() again, or using string manipulation, I now patched pathinfo() to provide the filename without extension per default with key "filename". Find the patch here: http://schlitt.info/misc/pathinfo.patch The patch is against 5_2. Maybe someone considers that useful as well? Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] array type hint and SPL array interfaces
Hi Jared Williams! On 05/09/06 13:17 you wrote: >> I wondered, why PHP complains, if you have an array type hint in a >> method prototype and provide an object to this method, that >> implements the SPL interfaces to use objects as arrays. I would >> expect that, if an object can be handled exactly like an array, PHP >> should not complain, since the implementation of the method would >> not notice the difference. Or am I wrong? > But the method may use an array_*() function, which would cause > problems if they're handed an ArrayAccess implementation. So there is > a difference. Ah, yes, you're right! Thanks for enlightening me! Regards, Toby -- Tobias Schlitt - Zend Certified Engineer NEW GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] array type hint and SPL array interfaces
Hi Marcus! I wondered, why PHP complains, if you have an array type hint in a method prototype and provide an object to this method, that implements the SPL interfaces to use objects as arrays. I would expect that, if an object can be handled exactly like an array, PHP should not complain, since the implementation of the method would not notice the difference. Or am I wrong? Regards, Toby -- Tobias Schlitt - Zend Certified Engineer NEW GPG Key: 0xC462BC14 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: PHP 6.0 Wishlist
Hi Davey Shafik! On 08/12/05 20:56 you wrote: > As little as it means, +1 Same from here! :) Cheers! Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Zeev Suraski! On 08/10/05 17:30 you wrote: > I think > that throwing exceptions in all sorts of places encourages people to > write 'exception-oriented' apps, which is very messy. Sorry, but I consider that statement wrong. We are still talking about PHP and a not caught exception will result into a fatal error. Therefore you do not force anyone to actually write 'exception-oriented' apps. > I believe we mentioned once the possibility of adding another error > level, which is fatal - but still catchable by set_error_handler(). What actually would be the same as having a try block around your application. > That is a good idea (which we should be doing either way). I definitly agree here, but it does not make sense for type hinting. But heaving the type hints throwing an exception is a really nice feature for large applications, where you are often not sure, which parts of the application will call a function or even worse you're not sure with which objects you act (because of utilizing multiple different libraries, written be even more different people). Having an exception thrown in that case enables you to run surrounded, independant modules to finish their work gracefully instead of shutting down the whole request gracefully. The actual implementation of type hints does not allow them to be used in this case, because having a coding error in just 1 module will screw up all other modules, where just 1 is broken. Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Fwd: FrOSCon - "FOSDEM" in Germany
Weiredly had the wrong adress in my contacts. So, here's what was intended to get here... Original Message Hi all! Sebastian has blogged [1] about FrOSCon, a pondon to FOSDEM in Germany, St. Augustin. If there is interesst, I'd love to see a PHP/PECL/PEAR room there. Sebastian is member of the organisation team, so I assume that should not be a problem. Interesst? Comments? Regards, Toby [1] http://www.sebastian-bergmann.de/blog/archives/520-FrOSCon.html P.S. Sorry for the x-post and please redirect flames on that directly to /dev/null. -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Marcus Boerger! On 08/08/05 19:58 you wrote: >>The point is, that it's senseless to have it throw any exception that >>can be disabled, when you want to write portable applications. In that >>case you still have to stick to catch Exception and have no benefit of >>it throwing anything else, when SPL is enabled. >>I would pretty much appreciate it having thrown an >>InvalidArgumentException, but then this should work everywhere. > If you plan to support PHP builds without SPL then that most likley means > that you have dropped other built-in default extensions too. Probably > because of their memory space to reduce loading time. In that case you are > not up for portability or have made a major mistake already in the > beginning. > Anyway there is no argument here. If you go for portable apps in the sense > that any extension can be diabled then catching plain Exceptions should be > more than good enough. You cannot expect to have full blown oo support when > you disable the one oo extension. That's the point: OO extension. I agree that things like iterators and stuff belong into SPL, since they're not standard OO features. But things like predefined exceptions belong into the engine. Especially those that get thrown by a PHP builtin feauture. Not to get me wrong, I'm strongly against having extensions itself or functions throw exceptions, but in the case we currently discuss, we are dealing with an OO feature of PHP, that should definitly throw it's own exception. Why else were exceptions invented when not to be used with OO features? > As a side note we could probably also move all exception declarations from > SPL to the engine but then we'd loose the possibility to support builds > without SPL. At the end of the day i'd even like to drop reflection support > from the engine and move it to a specialized extensions - again - for > speed/memory reasons. Having all exceptions in the engine sounds much overhead. But some well defined ones that get utilized by PHP OO features would definitly make sense. In the end, I have not a real problem with any solution, as long as OO features start throwing exceptions instead of raising errors. :) Regards, Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Johannes Schlueter! On 08/08/05 14:50 you wrote: >>> The throw an Exception when SPL disabled and an InvalidArgumentException >>> when it is enabled. >>That's senseless when writing applications that shall be version >>independant. Just sticking to Exception should be fine. > No it is not, in your application you can still simply catch Exception to be > independent of SPL since the InvalidArgumentException class extends the > Exception class. But by using nested Exceptions you can catch them > independently. Else you would have to catch every Exception, parse the error > message or trace to see wether it was a problem while calling the > function/method or some code inside the function/method went wrong. The point is, that it's senseless to have it throw any exception that can be disabled, when you want to write portable applications. In that case you still have to stick to catch Exception and have no benefit of it throwing anything else, when SPL is enabled. I would pretty much appreciate it having thrown an InvalidArgumentException, but then this should work everywhere. Regards, -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] type hinting throwing a fatal error
Hi Sebastian Bergmann! On 08/08/05 13:32 you wrote: >>Won't work, SPL can be disabled. > The throw an Exception when SPL disabled and an InvalidArgumentException > when it is enabled. That's senseless when writing applications that shall be version independant. Just sticking to Exception should be fine. Regards, -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CVS Account Request: kore
Hi all! On 07/19/05 08:10 Kore Nordmann wrote: Pear package maintaining (Image_3D) http://pear.php.net/pepr/pepr-proposal-show.php?id=261 http://pear.php.net/package/Image_3D/ Just to acknowlegde this. Kore is the lead maintainer of Image_3D, please create the cvs account and grant karma to pear/Image_3D/. Thanks in advance! Toby -- Tobias Schlitt - Zend Certified Engineer GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] GIF support for PHP4(/5)
Sorry, it's late here... website that really works in every browser the same, you cannot count on GIF, since some more actual browsers still do not support PNG s/GIF/PNG/ -- Tobias Schlitt GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] GIF support for PHP4(/5)
Hi all! I definitly know, that GIF is an outdated and today a bit crappy graphics format and that PNG is much nicer and cooler. Myself would not even use the GIF creation in PHP anymore and did not do for years. But beside that I know, that there still are (huge) companies, which force their employees to be compatible to very very outdated browsers (NS 4 and below), which do not support PNG. And if you want to create a website that really works in every browser the same, you cannot count on GIF, since some more actual browsers still do not support PNG transparency correctly. So, please do all those poor souls a big favor and reintegrate the GIF creation support back into an actual PHP version (4.3.9 / 5.1.0??). Thanks a lot in advance! Regards, Toby -- Tobias Schlitt GPG Key: 0xA6529579 a passion for phphttp://www.schlitt.info Like to say "thank you"?- http://pear.php.net/wishlist.php/toby -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
