Re: [PHP-DEV] Make try/catch brackets optinal
This reminds me of
$var = something or die();
So if you do follow with braceless-try, I would have
try something() catch($e) do_something_with($e);
Or (a bit simpler, but assumes we have a new pseudovariable $e),
try something() or do_something_with($e)
I don't like the form with a semicolon, because what if there are two
semi-colons after the statement? What does the try statement wrap?
try something();; catch ($e) { ... }
The whole concept breaks away from the tradition of wrapping massive
blocks with try { } statements, and might make applications use
exceptions a LOT more freely. Something to keep in mind.
Jevon
On Fri, Jul 20, 2012 at 12:30 AM, Lester Caine wrote:
> Peter Beverloo wrote:
>>
>> Other bracket-less blocks allow authors to shoot themselves in the foot
>> equally so, yet PHP supports these as well. The actual problem here is an
>> inconsistency in the parser, which I'd consider to be a bug.
>
>
> Having been caught out too many times now when adding an extra part to code
> there 99% of the blocks are correctly wrapped ... when I see code without
> the brackets they get added! The bug as far as I am concerned is NOT
> reporting them missing but just getting them displayed in eclipse would do
> me for now ;)
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
>
>
> --
> 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] Generators in PHP
I don't understand why you need to introduce two new keywords into the
language - * and yield. Could you not solve it like follows?
// Generator implements Iterable
class AllEvenNumbers extends Generator {
private $i;
public __construct() { $this->i = 0; }
function generate() {
return ($this->i++) * 2;
}
}
That way I think you can persist state (as part of the class instance)
and implement rewind (per whichever way you do it - either caching the
output, or serialising the class instance) without having to introduce
yet more keywords.
If this is instead a discussion to specifically implement yield,
rather than simplifying the implementation of rewindable Iterators, it
might be more useful to frame the discussion in that way.
Jevon
On Wed, Jun 6, 2012 at 5:35 AM, Nikita Popov wrote:
> Hi internals!
>
> In the last few days I've created a proof of concept implementation
> for generators in PHP. It's not yet complete, but the basic
> functionality is there:
> https://github.com/nikic/php-src/tree/addGeneratorsSupport
>
> The implementation is outlined in the RFC-stub here:
> https://wiki.php.net/rfc/generators
>
> Before going any further I'd like to get some comments about what you
> think of adding generator support to PHP.
>
> If you don't know what generators are you should have a look at the
> "Introduction" section in the above RFC or in the Python documentation
> at http://wiki.python.org/moin/Generators.
>
> Nikita
>
> --
> 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] Unicode Implementation
Ditto please! Jevon - Original Message - From: "Ron Korving" <[EMAIL PROTECTED]> To: Sent: Thursday, October 13, 2005 8:27 PM Subject: [php] Re: [PHP-DEV] Unicode Implementation > Well, if you want my 2 cents as well, the 2 cents a PHP user is very willing > to share with you guys... > > PHP6 is a major release. BC is a priority, but as far as I'm concerned not > the top priority. I wouldn't mind a unicode-only PHP at all. Like a few > others here, I think the speed penalty won't be huge at all. It's not like > my scripts are 90% string handling (and I assume the unicode benchmark > scripts are). I wouldn't want you guys having a messy codebase just because > you want to support non-unicode and unicode. I also wouldn't want you guys > branching to a non-unicode line of PHP releases. It would just be too much. > As far as I'm concerned, I'd be fine with a unicode only PHP6. Unicode is > progress. I think a lot of the people who don't want it, don't yet see the > positive things it brings. > > Ron > > > > "Peter Brodersen" <[EMAIL PROTECTED]> schreef in bericht > news:[EMAIL PROTECTED] > On Sun, 9 Oct 2005 00:55:45 -0400 (EDT), in php.internals > [EMAIL PROTECTED] (Adam Maccabee Trachtenberg) wrote: > > >We seem to be under the impression that the Unicode speed penalty will > >be so harsh that a Unicode-only PHP 6 will be too slow for > >use. However, we don't know that for sure. Yes, it will be slower, > >when you look at the whole request cycle, it may not matter. > > I agree - the speed penalty comparsion seems mostly related to php > scripts that does nothing else than handling strings. > > I recall the old discussions (echo vs print vs ?>... benchmarks. It is true when you compare the specific > functions/language constructs the relative difference in speed is > apparent. But compared to a bunch of other functions that you'll > usually use (database connections, file access, data sorting, etc.) I > imagine that the speed penalty is simply marginal. > > Just my 0.02 \x20B1. > > -- > - Peter Brodersen > > -- > 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] dropping curly braces
Is there anything wrong with having a convention for character access of
strings? Most PHP programmers see {} as string access and [] as array access -
sure, they might be functionally identical, but its the convention which is
important.
Jevon
> ---Original Message---
> From: Rasmus Lerdorf <[EMAIL PROTECTED]>
> Subject: Re: [PHP-DEV] dropping curly braces
> Sent: 17 Nov '05 12:11
>
> Andreas Korthaus wrote:
> >> As far a code readability and obviousness goes, I doubt anybody would
> >> guess their way to the $str{5} syntax.
> >
> > But you know without understanding of any context, that it's the 6th
> > character of the string "$str". When you see $var[5], it could be the
> > 6th character of a string, or an element of an array... and what about
> > the value? You can't be sure that it's a string with length 1, it also
> > could be another array, an object, a string with length 4711...
> >
> > That increases complexity and decreases readability.
>
> Your argument falls apart there. Try it:
>
> $a = array("ab","cd","ef");
> echo $a{2};
>
> Guess what that prints? {} has nothing to do with strings. They are
> 100% equivalent to [] and as such add nothing to clarity.
>
> -Rasmus
>
> --
> 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:
So does that mean the new NS operator is actually \\ and not \ ? No developer is going to be relying on single \'s -- too likely to become an error in maintenence, and too inconsistent (see strings discussion). Jevon On Tue, Oct 28, 2008 at 12:11 AM, Arvids Godjuks <[EMAIL PROTECTED]>wrote: > This was argued for months, there was tons of emails to read and backslash > is best for most people. PHP is dynamic language - that makes some major > restrictions, so you just can't apply something that is already in use > easily. That's why :: was rejected in first place. That's why . was > rejected, other separators had other issues. Backslash is easy to see, easy > to type (most layouts have it without Shift or something else) and clearly > says - I'm a namespace! > So anyway - in any language you will find something that you would't like. > You just live with that or chouse another language. That's all. > > 2008/10/27 Thomas Lee <[EMAIL PROTECTED]> > > > Lester Caine wrote: > > > >> The backslash is not ideal, but I think we all need to get behind it > >> rather than complaining. The only other real alternative today is to > shelve > >> namespaces altogether for the next release rather than putting something > in > >> that is simply not practical to extend later? > >> > > I'd prefer to see it shelved for another release with the aim of fixing > > whatever technical barriers made the syntax unworkable in the first > place. > > I'm sure you'd have plenty of volunteers. > > > > My personal concern is that once this goes public, we (the end users) are > > stuck with that decision for the forseeable future. > > > > I think there's obviously enough unhappy campers here that this option > > should be at least considered. Not that I'm holding my breath or > anything. > > > > Everybody seems to be getting awfully emotional about this ... > > > > Cheers, > > > > T > > > > > > -- > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > >
Re: [PHP-DEV] Adding a more logical string slicing function to PHP
If substr() really was so bad, then surely we'd see userland implementations of str_slice() in every project? Jevon On Wed, Mar 30, 2011 at 7:06 PM, Dan Birken wrote: > My apologizes if I am bringing up a topic that has been discussed before, > this is my first time wading into the PHP developers lists and I couldn't > find anything particularly relevant with the search. > > Here is a bug I submitted over the weekend ( > http://bugs.php.net/bug.php?id=54387) with an attached patch that adds a > str_slice() function into PHP. This function is just a very simple string > slicing function, with the logical interface of str_slice(string, start, > [end]). It is of course meant to replace substr() as an interface for > string slicing. > > I detailed the reasons I submitted the patch in the bug a little bit, but > the main reason is that I think the substr() function is really overly > confusing and just not an intuitive method of string slicing, which is > exceedingly common functionality. I realize we don't want to go around > adding lots of random little functions into the language that don't offer > much, but the problem with that is that if we have a function like substr() > with an unusual and unintuitive interface, it becomes unchangeable due to > legacy issues and then you can never improve. I think this particular > functionality is important enough to offer an updated interface. In the bug > I also pointed to two related bugs that would be essentially fixed with this > patch. > > -Dan > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Multi-Method Dispatch in PHP 5.1?
But at the same time, it would be nice to have a standardised multi-method syntax or code - or users might develop their own weird and wacky, inconsistent ways of implementing it. Perhaps the code submitted before could be included in the PHP documentation, telling users on how they could emulate this style of code? Jevon - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Christian Schneider" <[EMAIL PROTECTED]>; "Michael Walter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, April 21, 2004 9:55 PM Subject: Re: [PHP-DEV] Re: Multi-Method Dispatch in PHP 5.1? > I don't want to prolong this discussion but I agree with the people who are > against multi-method dispatch. I don't think it makes much sense in PHP, > and I think that in the few places where someone really feels they need it, > it can be implemented in user-land. It's just going to complicate the > language for a small minority of people who feel they need this feature. > > 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] [RFC] Type hints
If so, maybe allow the type hint to always succeed, if it's got NULL as the
default parameter?
(that way foo() wouldn't act differently to foo(NULL), even though they both
mean the same thing, ignoring the type hint)
Jevon
- Original Message -
From: "Timm Friebe" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 11, 2004 9:44 PM
Subject: Re: [PHP-DEV] [RFC] Type hints
> On Mon, 2004-05-10 at 18:16, Andi Gutmans wrote:
> > I think it's hard to put closure on this type hints issue.
> [...]
> > As no good syntax has been found for the less common case of allowing
> > NULL's, I think the best solution for now is not to allow null in the
> > regular type hint syntax, and have people who want to allow NULL's not
use
> > type hints at all (in any case, they need to manually check their
parameter
> > so they'll do one more manual check).
>
> Will this affect optional arguments? I.e., will the following still
> work?
>
> class UserClass {
> public static function forName($name, ClassLoader $c= NULL) {
> // ...
> }
> }
>
> $works= UserClass::forName('MySQLConnection');
>
> (not passing any value for the optional parameter) vs.
>
> $fails= UserClass::forName('MySQLConnection', NULL);
>
> (passing NULL as "value" for the optional parameter)
>
> - Timm
>
> --
> 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] Implicit Arrays and E_STRICT
Won't you then have to recursively initialise multiple dimension arrays? $a = array(); $a[0] = array(); Otherwise, isn't this implicitly creating arrays? (I didn't quite understand the last time) Jevon - Original Message - From: "Jason Garber" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, May 08, 2004 12:25 PM Subject: Re: [PHP-DEV] Implicit Arrays and E_STRICT > I would view implicit array creation as a slightly negative thing, similar > to accessing the value of a variable that does not exist. > > We run in E_ALL mode and write our code to avoid all E_NOTICEs. For > instance, before using an array, I always initialize it using $aItems = > array(); > > I'm in favor of issuing an E_NOTICE in response to this. > > ~Jason > > At 5/8/2004 12:43 AM +0200, Marcus Boerger wrote: > >Hello Sara, > > > >i like to see one of those too and i have no preference for one of them. > > > >marcus > > > >Friday, May 7, 2004, 11:05:15 PM, you wrote: > > > > > This topic got quietly dropped last week, but I'd like to make one last > > > plea. I'd like to see Zend throw an E_STRICT when arrays are implicitly > > > created. I know there were objections to E_NOTICE, but did anyone have > > > violent objections to E_STRICT? > > > > > -Sara > > > > > > > > > >-- > >Best regards, > > Marcusmailto:[EMAIL PROTECTED] > > > >-- > >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] Read PHP script from...
Well, if you can get the file source out of the archive into a string, you could then eval() it. Hope this helps, Jevon - Original Message - From: "Srdjan Mijanovic" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, May 08, 2004 5:51 AM Subject: [PHP-DEV] Read PHP script from... > Hello, > > I'm quite new to this newsgroup, and I hope this is the right place to ask > the question. > > I want to be able to read PHP source files from an archive. Script is not > present on the hard disk, but inside a file / archive. To do this, I can > supply the zend_stream object for reading and writing. > > How to integrate this into the ISAPI PHP? The major problem is with INCLUDE > function, which always assumes that we're including files from the disk... > while the content can come from other sources (archive) > > Thanks! > > Regards, > > Srdjan Mijanovic > > -- > 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] [PATCH] Repost - Adding Output Filters w/ Apache2 Handler SAPI
What if you extended this to cover PHP in general - you could make your PHP always generate XML data and then with add_output_filter(proprietary string or callback function) you could make PHP transform the output at the end of the script execution (possibly multiple times). I know a lot of developers which are interested in a script -> xml -> xml -> xml -> xhtml pipeline, and something like add_output_filter() might be a godsend :) Yeah, I know it can be done in userland (somewhat)... Jevon - Original Message - From: "Edward Rudd" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, April 30, 2004 1:31 PM Subject: Re: [PHP-DEV] [PATCH] Repost - Adding Output Filters w/ Apache2 Handler SAPI > Woohoo! > This is an awesome patch.. > I hope it gets accepted into PHP proper. > > On Mon, 26 Apr 2004 11:33:48 +0300, Andi Gutmans wrote: > > > Can you please give an example on how this can be used? > > > > I am using it in a PHP web app I am writing where I am generating XML > output and running it through an XML filter via XSLT (mod_transform). And > I can then selectively turn the filter on and off.. IE for XML data that I > don't want transformed, or for non-xml data. > > > At 08:13 PM 4/25/2004 -0600, Paul Querna wrote: > >>I added two new functions for handling output filters in the > >>Apache2Handler SAPI: > >> > >>bool apache_add_output_filter(string filter_name) - Attempts to add the > >>named filter to the Filter Chain. > >> > >>array apache_get_output_filters() - Returns an array of all Active > >>Output filters for this request > >> > >>The ability to add an output filter is very helpful in the apache > >>2model. For example with this I was able to add an XSLT output filter > >>that I use in other areas to render XML generated from PHP to HTML. > >> > >>The attached patches are for both PHP4 CVS and PHP5 CVS. They are also > >>online at: http://force-elite.com/~chip/patches/php-src/apache2-filters/ > >> > >>I posted this patches last Monday, but received 0 replies. Are the > >>patches acceptable, is there anything to change, or are there any > >>comments? > >> > >>Thanks, > >> > >>-Paul Querna > >> > >> > > -- > 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] nested includes fails?
I tested it on PHP 5 RC1, Win XP SP1, IIS 5.1 running as CGI - it didn't
fail.
I tried it on PHP 5 RC2, Win XP SP1, IIS 5.1 running as CGI - it didn't fail
then, either.
(Calling c.php)
a.php
b.php
c.php
common.php
Jevon
- Original Message -
From: "Tumurbaatar S." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, May 04, 2004 5:25 PM
Subject: [PHP-DEV] nested includes fails?
> 'common.php' contains some class definition and PHP5 fails with
> 'PHP Fatal error: Cannot redeclare class ... in common.php...' when
> script C.php starts. The file including map is:
>
> A.php: require_once(common.php)
> B.php: require_once(common.php)
> C.php:
> require_once(A.php)
> require_once(B.php)
>
> That is bug? When only one file is included (A or B),
> the contents of 'common.php' is available, i.e. nested require
> works. Only fails when nested and multiple require.
>
> P.S. I use PHP5 RC2 running as CGI on WinXP/IIS.
>
> --
> 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] nested includes fails?
Sorry for the delay...
I didn't quite understand the problem, but I've tried to reproduce it:
-
\inc\a.php
\inc\b.php
\inc\common.php
\inc\member.php
\inc\foo.php
-
\member\member.php
\member\member2.php
\member\member3.php
-
I can access \member.php, \member2.php and \member3.php all fine with no
errors.
Perhaps you've got a "common.php" in the \member directory? Because
require_once("common.php") will use *that* common.php instead (and not the
one in \inc\).
Jevon
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Jevon Wright" <[EMAIL PROTECTED]>; "Tumurbaatar S."
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Tuesday, May 04, 2004 11:50 PM
Subject: Re: [PHP-DEV] nested includes fails?
> Can you give it a try with relative patches the way Tumurbaatar did?
>
> Andi
>
> At 11:41 PM 5/4/2004 +1200, Jevon Wright wrote:
> >I tested it on PHP 5 RC1, Win XP SP1, IIS 5.1 running as CGI - it didn't
> >fail.
> >I tried it on PHP 5 RC2, Win XP SP1, IIS 5.1 running as CGI - it didn't
fail
> >then, either.
> >(Calling c.php)
> >
> >a.php
> >
> >
> >b.php
> >
> >
> >c.php
> > > require_once("a.php");
> > require_once("b.php");
> > ?>
> >
> >common.php
> >
> >
> >Jevon
> >
> >- Original Message -
> >From: "Tumurbaatar S." <[EMAIL PROTECTED]>
> >To: <[EMAIL PROTECTED]>
> >Sent: Tuesday, May 04, 2004 5:25 PM
> >Subject: [PHP-DEV] nested includes fails?
> >
> >
> > > 'common.php' contains some class definition and PHP5 fails with
> > > 'PHP Fatal error: Cannot redeclare class ... in common.php...' when
> > > script C.php starts. The file including map is:
> > >
> > > A.php: require_once(common.php)
> > > B.php: require_once(common.php)
> > > C.php:
> > > require_once(A.php)
> > > require_once(B.php)
> > >
> > > That is bug? When only one file is included (A or B),
> > > the contents of 'common.php' is available, i.e. nested require
> > > works. Only fails when nested and multiple require.
> > >
> > > P.S. I use PHP5 RC2 running as CGI on WinXP/IIS.
> > >
> > > --
> > > 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] nested includes fails?
I tried this and it didn't fail...
Jevon
- Original Message -
From: "Tumurbaatar S." <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 1:32 PM
Subject: Re: [PHP-DEV] nested includes fails?
> Hi, Jevon,
> Mine is not so complex:
>
> //all files in 'inc' include 'common.php'
> \inc\a.php
>require_once("common.php");
> class A { }
> ?>
> \inc\b.php
> require_once("common.php");
> class B {}
> ?>
>
> //common.php does not include anything
> \inc\common.php
> class C { }
> ?>
>
> //this works. Main scripts include 'common.php' indirectly
> \member\member.php
> require_once("../inc/a.php");
> ?>
>
>
> //this fails:redeclaration of class C
> \member\member3.php
> require_once("../inc/a.php");
> require_once("../inc/b.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] Reflection API : Feature request and question
- Original Message -
From: "Arjen Warendorff" <[EMAIL PROTECTED]>
To: "'PHP Internals List'" <[EMAIL PROTECTED]>
Sent: Wednesday, May 05, 2004 7:33 PM
Subject: [PHP-DEV] Reflection API : Feature request and question
> Hello,
>
> I have played around with the Reflection API, missed some features and
have
> some questions:
>
> At the moment there is no way of checking if a default parameter has a
> value, and if so, to get it's value. Example:
> function foo($bar = TRUE) {}
> The default value for $bar would be TRUE in this example (maybe a
> "hasDefaultValue()" and a "getDefaultValue()" method?).
I reported this in my bug:
http://bugs.php.net/bug.php?id=28241
It was suspended until PHP 5.1... but yes, I really think the Reflection API
needs this!
> The ReflectionFunction method "getStartLine()" would be, in my opinion)
> become even more usefull if you had something like a "getLine()" method
> which should return the source code on that line, but i might be out of my
> league here. :)
Couldn't you do this in userland? Which the PHP internals seem so obsessed
about :D
I don't know if this is truly useful - maybe if the PHP code is stored in
memory anyway, and it doesn't introduce a performance penalty...?
Jevon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Use of 'self' in static function in subclass
It's something I noticed, too. Consider this:
class A {
function a() { return $this::b(); }
function b() { return 1; }
}
class B extends A {
function b() { return 2; }
}
If I call
$b = new B();
echo $b->a();
No matter what combination of this, self, parent, ... - I could never get
B's property. I was led to believe that this is actually normal for OO
designs (is it? If so, ignore me). But it would be awesome if self or $this
(ONLY one of them, if they currently perform the same function) actually
referred to the top class - ie. B::b() in this case. Is this what this
suggestion would suggest?
Thanks,
Jevon
- Original Message -
From: "Adam Bregenzer" <[EMAIL PROTECTED]>
To: "Hans Lellelid" <[EMAIL PROTECTED]>
Cc: "Ferdinand Beyer" <[EMAIL PROTECTED]>; "Timm Friebe" <[EMAIL PROTECTED]>;
<[EMAIL PROTECTED]>
Sent: Wednesday, June 02, 2004 12:26 PM
Subject: Re: [PHP-DEV] Use of 'self' in static function in subclass
> On Tue, 2004-06-01 at 19:53, Hans Lellelid wrote:
> > Yeah +1 on self:: binding at runtime. I can't really imagine a case
> > where you would want to refer to 'self' as the class that contains the
> > method *and not* the overridden method in invoked class (if it exists).
> > Binding this at runtime will introduce many new design possibilities
> > with static classes and will also make self:: consistent with $this->
> > behavior for objects.
>
> +1, I agree completely. I think it is critical to have a way to be able
> to have a static method call another static method in the same class
> that respects inheritance. If a developer wanted a call to not respect
> inheritance the class's name can be used instead of self with the same
> results (increased code maintenance should the class name change
> notwithstanding).
>
> --
> Adam Bregenzer
> [EMAIL PROTECTED]
> http://adam.bregenzer.net/
>
> --
> 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] stripslashes() improvements
> echo "Stripslashes test: ";
> ini_set('magic_quotes_sybase', 0);
> $s = 'c:\\windows\\system32';
> $s1 = '\\';
> if ($s == stripslashes($s) && $s1 == stripslashes($s1)) echo "OK\n";
> else echo "FAILED\n";
> ?>
'c:\\windows\\system32' becomes 'c:\windows\system32' in memory (the slashes
are stripped).
stripslashes() will make it 'c:windowssystem32'. Thus the above tests will
fail.
This isn't a bug? (Doesn't magic_quotes_sybase only override
magic_quotes_gpc which affects GPC data?)
Jevon
- Original Message -
From: "Alexander Valyalkin" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, June 09, 2004 10:52 PM
Subject: Re: [PHP-DEV] stripslashes() improvements
> On Tue, 8 Jun 2004 16:03:19 +0200 (CEST), Derick Rethans <[EMAIL PROTECTED]>
> wrote:
>
> >
> > You'll have to proof that by writing testcases, for example try it with
> > the test cases in the current source and write new ones for things that
> > we don't have a test case for yet.
> >
> >> -PHPAPI void php_stripslashes(char *str, int *len TSRMLS_DC)
> >> +PHPAPI void php_stripslashes(char *str, size_t *len TSRMLS_DC)
> >
> > You can't just change the API call, that will break things.
> >
> >
> > regards,
> > Derick
>
> Ok. First of all, my version of the stripslashes() solves following bugs:
> #9437
> #19947
> #27848
>
> I have successfully tested my code with test case from current source
> /ext/standard/tests/strings/add-and-stripslashes.phpt
>
> And here is my testcase, related to mentioned bugs:
>
> echo "Stripslashes test: ";
> ini_set('magic_quotes_sybase', 0);
> $s = 'c:\\windows\\system32';
> $s1 = '\\';
> if ($s == stripslashes($s) && $s1 == stripslashes($s1)) echo "OK\n";
> else echo "FAILED\n";
> ?>
>
> Here is corrected code with standart API call:
> cut==
> PHPAPI void php_stripslashes(char *str, int *len TSRMLS_DC)
> {
> char *s, *t;
> size_t l;
> size_t dst_len; /* length of the stripped string */
>
> if (len != NULL) l = dst_len = (size_t) *len;
> else l = dst_len = strlen(str);
> if (l < 2) return; /* there is no characters to strip */
> s = t = str;
>
> if (PG(magic_quotes_sybase)) { /* sybase magic_quotes ( '' -> ',
\0 ->
> NULL) */
> while (l > 1) {
> if (*t == '\'' && *(t + 1) == '\'') {
> *s++ = '\'';
> t += 2;
> l--;
> dst_len--;
> } else if (*t == '\\' && *(t + 1) == '0') {
> *s++ = '\0';
> t += 2;
> l--;
> dst_len--;
> } else *s++ = *t++;
> l--;
> }
> } else { /* ordinary magic_qoutes (not sybase) ( \\ -> \, \' -> ', \"
> -> ", \0 -> NULL) */
> while (l > 1) {
> if (*t == '\\') {
> t++;
> switch (*t) {
> case '\\' :
> case '\'' :
> case '"' :
> *s++ = *t++; dst_len--; break;
> case '0' : *s++ = '\0'; t++; dst_len--; break;
> default : *s++ = '\\'; *s++ = *t++; break;
> }
> l -= 2;
> } else {
> *s++ = *t++;
> l--;
> }
> }
> }
> if (l == 1) *s++ = *t; /* copy the last symbol */
> if (len != NULL) *len = (int) dst_len; /* set length of the stripped
> string */
> *s = '\0';
> }
> cut==
>
> diff:
> cut==
> --- string.cThu May 13 20:44:32 2004
> +++ string_new.cWed Jun 09 13:47:21 2004
> @@ -2159,70 +2159,51 @@
> PHPAPI void php_stripslashes(char *str, int *len TSRMLS_DC)
> {
> char *s, *t;
> - int l;
> -
> - if (len != NULL) {
> - l = *len;
> - } else {
> - l = strlen(str);
> - }
> - s = str;
> - t = str;
> +size_t l;
> +size_t dst_len; /* length of the stripped string */
>
> - if (PG(magic_quotes_sybase)) {
> -
Re: [PHP-DEV] Re: keyword arguments?
Wouldn't a good (not necessarily better) idea in your case be to use an
object?
Instead of
function foo(named $a, named $b, named $c, named $d, ..., named $z)
echo foo(a := $a, c := $c, e := $e, ...);
you'd have
class Foo { ... }
$f = new Foo();
$f->setA($a);
$f->setC($c);
$f->setE($e);
...
echo $f->doit();
This is clearer; all arguments are optional (unless you want to put required
arguments in a constructor); and it basically does the same thing. And yes,
it's about as much work as having a hash.
Visual Basic supports named arguments (I used its style above). I've used it
once in a function, but it had like 10 arguments - and it was a nightmare to
try and code. I don't think the solution to extending functionality is to
just add more arguments! Then again, I am still trying to instruct myself to
the OO paradigm.
What happens if you want to remove an argument from a function with named
arguments? Either you'll have to remove it and search through all code and
amend the calls (tiresome, error-prone), or you'd label the parameter
"unused"/"deprecated". What happens if your function kept on changing?
Before long you'll have 100 arguments with only 10 of them used at any one
point... Just some thoughts...
Jevon
- Original Message -
From: "Richard Mann" <[EMAIL PROTECTED]>
To: "Daniel Crookston" <[EMAIL PROTECTED]>; "Bert Slagter"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Thursday, June 24, 2004 8:53 PM
Subject: RE: [PHP-DEV] Re: keyword arguments?
> >pretty soon you have function calls that look like this:
> >
> >xyz('a', 2, $foo, '', '', '', '', '', '', $bar);
>
> I agree with this. I am working on a project where by the flexibility
> required of the object being written has spawned a massive collection of
> parameters. Many of these parameters are only required in certain
situations
> and it is indeed the case that when I need to add one additional parameter
> to accommodate some new capability, I suddenly find myself with the task
of
> either putting all the empty parameters in before it every time it is used
> or rewriting all instances of the function to place it towards the
> beginning.
>
> I can except that this can be avoided in many cases with better
> forward-planning, but it is defiantly desirable sometimes to simply have
> these flexible constructs available.
>
> >all that can be offset by write a complementary set of wrapper functions
> >like:
> >
> >function xyzSuperSpecialFooBar($a, $b, $foo, $bar) {
> >/* using the 7th optional arg - first 3 args required (or whatever)
*/
> >return xyz($a, $b, $foo, '', '', '', '', '', '', $bar);
> >}
>
> Not always ideal though. Having about 6 different aliases for essentially
> one function can get confusing for the developer to remember. My example
is
> a HTML Form generator, whereby the actually generation of the form
elements
> is alike enough to be handled by one algorithm, but requires some set-up,
> which includes various layout settings. I could do this with a different
> alias for each element, but this is more difficult to automate then simply
> passing a 'type' variable which can easily be programmed.
>
> Having said my peace in favour of named keywords (which I do think would
be
> extremely handy), I must say that I am not convinced by any of the syntax
> put forward for using them yet. :-( Maybe something like:
>
> function a($a, $b=true, $c=>false) {
> ...
> }
>
> $c would be your named parameter.
>
> Sorry for dragging up old stuff. ;-)
>
>
> Subject: Re: [PHP-DEV] Re: keyword arguments?
>
>
> The major benefit of keyword arguments doesn't occur when you're writing
> functions, it occurs when you're re-writing them. I can't count the
> number of times where I've thought "My xyz function already does something
> almost exactly like what I need... if I just passed it an extra parameter,
> I could rewrite xyz to do what I need and save a lot of time." So I add
> another parameter, making it optional.
>
> This is fine, all the calls to xyz that are lacking the final parameter
> still work (since it's optional.) But do this once or twice, and pretty
> soon you have function calls that look like this:
>
> xyz('a', 2, $foo, '', '', '', '', '', '', $bar);
>
> That's ugly and unnecessary, and leaves lots of room for bugs when you're
> writing functions that use the nth optiona
Re: [PHP-DEV] GOTO operator
Why not make it hard for users to use GOTO in the first place?
Develop some wacky construct that you have to use instead... that way, it
will scare off novice users, and expert programmers will HAVE to know what
they're doing and know that they really need it before they have to
implement it. It's along the lines of "make the most dangerous stuff the
hardest to do".
I'm not sure how, though... a huge language construct
(goto_this_line_please)? Use numbers instead of labels? Relative jumping?
Require extra messages? A weird symbolic construct? *shrug*
On another note, if a GOTO was added, the ability to go " goto foo$bar "
(dynamic goto) could add another gold star onto PHP's coolness.
Jevon
- Original Message -
From: "Frank M. Kromann" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Friday, July 30, 2004 11:15 AM
Subject: Re: [PHP-DEV] GOTO operator
> We were all newbies at some point and most of us (not including myself)
> learned how to handle the language, and so will the newbies of today, even
> if GOTO is a part of the language. I don't see a need to make this an
> ini-option. It is allready an option - use t or leave it alone.
>
> - Frank
>
> > Hello,
> >
> > I think we should add an INI option:
> >
> > php_newbie true|false
> >
> > ;)
> >
> > --
> > Best regards,
> > Jasonmailto:[EMAIL PROTECTED]
> >
> > Thursday, July 29, 2004, 8:54:34 PM, you wrote:
> >
> > AH> Sara Golemon wrote:
> > >>>do {
> > >>> .code...
> > >>> if (something) break;
> > >>> ...code
> > >>>} while (0);
> > >>>...cleanup code...
> > >>>
> > >>
> > >> Are you suggesting a hack is better than the real thing?
> > >>
> > >> -Sara
> > AH> The "hack" is working. The manual says :
> > AH> " Advanced C users may be familiar with a different usage of the
> do..while loop,
> > AH> to allow stopping execution in the middle of code blocks, by
> encapsulating them
> > AH> with do..while (0), and using the break statement. The following
> code fragment
> > AH> demonstrates this:" (a similar code follows)
> > AH> " Don't worry if you don't understand this right away or at all. You
> can code scripts
> > AH> and even powerful scripts without using this 'feature'. "
> > AH> (the manual states that people can code powerful things without goto
> hack).
> > AH> Sara, if you need to have the goto, you know how to implement it
> with do..while.
> > AH> The average Joe may not need goto in some case but he will find that
> it simplifies
> > AH> his job (but making code clumsy, something what he does not
> realize).
> > AH> It is not because I don't like the power of goto, I would like not
> to be given in the
> > AH> hands of the newbie.
> >
> > AH> andrey
> >
> >
> > --
> > 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] Date Support
I always wished that PHP had VB's set of operators on dates/times... (and
also in SQL): year(), month(), date(), time_serial(), and the like. Yes, you
can do it with date("...", $x); but then it's just awkward to remember all
the operators.
Also, I'd always wished that PHP would have support for dates after 32 bit
(2037)... when do you think Pecl's Date would get into PHP?
Jevon
- Original Message -
From: "Jason Garber" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, August 03, 2004 2:36 PM
Subject: [PHP-DEV] Date Support
> Hello internals,
>
> Not to take away from the wonderful and lively "GOTO" discussion,
> but... I've got a couple simple questions.
>
> 1. Is there a particular reason that PHP does not have a really good
> set of functions for dealing with true date and time types (i.e. not
> timestamps)?
>
> 2. I think that good date and time handling in PHP would be a
> large plus. MySQL provides, imho, a very effective set of tools for
> handling dates. I think that this style of date handling, where the
> standard format was -MM-DD HH:MM:SS would be an ideal way to go.
> Comments?
>
> 3. If there is no good reason for not adding this set of functions
> to the PHP core, what would be the method of designing an acceptable
> set of functions?
>
> PHP is a feature packed language, but it's strange that this does not
> exist in the core. Thanks for your time.
>
> --
> Best regards,
> Jason Garber mailto:[EMAIL PROTECTED]
> IonZoft, Inc.
>
> --
> 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] is_a() vs. instanceof
What about:
if (get_class($obj) == "unloadedclass") {
// blah
}
Jevon
- Original Message -
From: "Al Baker" <[EMAIL PROTECTED]>
To: "Hans Lellelid" <[EMAIL PROTECTED]>
Cc: "Dan Ostrowski" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, August 12, 2004 9:58 PM
Subject: Re: [PHP-DEV] is_a() vs. instanceof
> I agree, that's the exact behavior I would like as well and what most
> people would expect.
>
> Al
>
> On Wed, 2004-08-11 at 23:52 -0400, Hans Lellelid wrote:
> > Alan Knowles wrote:
> >
> > > I think he's referening to something like this (which is common in
pear):
> > >
> > > $x = $someobj->somemethod();
> > > if ($x instanceOf PEAR_Error) {
> > > ...
> > > }
> > >
> > > while that code is redundant in the case of exceptions, it is still a
> > > valid situation.. that $x may be a valid return, and PEAR_Error was
> > > never loaded..
> >
> >
> > Yup, that's exactly what I'm talking about.
> >
> > I want to be able to do this:
> >
> > if ($db instanceof DBPostgres) {
> >/// do something funky specific to Postgres
> > }
> >
> > If My DB adapter is DBMySQL, I don't want to load the DBPostgres adapter
> > just so I can test whether my object is of that type ...
> >
> > and checking first whether class_exists('DBPostgres') just seems kinda
> > kludgy & straying from the "problem domain" ... especially since $db
> > instanceof DBPostgres would *always* be false if DBPostgres isn't
loaded.
> >
> > Hans
> >
>
> --
> 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] Type hints with null default values
Alternatively, you could try to support polymorphism in classes :o) Then you
wouldn't need null references...
class X {
function a();
function a(MyObj $b);
}
Jevon Wright
- Original Message -
From: "Robert Silva" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Sunday, October 17, 2004 11:24 AM
Subject: RE: [PHP-DEV] Type hints with null default values
> PHP doesn't have a concept of a "null" reference though. So to say that
> every other language allows it is not a valid argument. The other
languages
> allow it because the language supports it. And that seems to be what the
> arguments against it centered around.
>
> I think a compromise would be to allow the argument to be optional but
still
> enforce the type hint. What this doesn't address fully is multiple
optional
> type hinted arguments.
>
> function A(ZObj $arg2=null, ZObj $arg3=null) {}
>
> How would you pass $arg3 if you didn't have anything to pass for $arg2.
> Maybe that's just an inherent restriction of the language...to pass $arg3,
> you have to pass a ZObj as $arg2.
>
> Someone else suggested adding null references to the language:
>
> ZObj $obj = null;
>
> But I don't think that is the right solution either not to mention the
> nightmare of actually implementing it.
>
>
> Bob
>
> -Original Message-
> From: Cristiano Duarte [mailto:[EMAIL PROTECTED]
> Sent: Saturday, October 16, 2004 3:01 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [PHP-DEV] Type hints with null default values
>
> Robert Silva wrote:
>
> > I think Marcus B's final comments in the original discussion are right
on
> > track.
> >
> > Stab: I voted for NULL type hinted arguments before I voted against
them.
> >
> > The main thing that changed my mind, is that in PHP there is no such
thing
> > as a NULL object. I came to the conclusion that PHP wasn't broken, my
> > programming style/code was.
> >
> > My opinion is that they should stay as they are now although personally.
> >
> > Now with that said, I do think there needs to be a method to allow a
type
> > hinted parameter to be optional (but not necessarily null).
> That's what I'm asking for. :-)
> I'm not asking for null objects, just an optional parameter that must be
an
> object or a "null" reference.
> All OO languages I've ever programmed had this kind of reference(Java,
C++,
> Delphi, etc.)
>
> Cristiano Duarte
>
> --
> 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] Nesting level too deep - recursive dependency?
I first stumbled upon this problem in one of the RCs for PHP 5, but at the
time I thought I was at fault...
Consider the documentation at
http://www.php.net/manual/en/language.oop5.object-comparison.php : the
documentation is a little vague, but it does say "Two object instances are
equal if they have the same attributes and values, and are instances of the
same class." Thus explaining the recursive loop...
Maybe write a big flashing note in the documentation instead about this
trap?
Jevon
- Original Message -
From: "Benj Carson" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, October 19, 2004 5:51 PM
Subject: Re: [PHP-DEV] Nesting level too deep - recursive dependency?
> If you use '===' it works as expected. I don't know if the fact that '=='
> doesn't work is a bug or not, however.
>
>
> Benj Carson
>
>
> On October 18, 2004 09:39 am, Francisco M. Marzoa Alonso wrote:
> > This code:
> >
> > >
> > class TestClass {
> > public $myself;
> >
> > function __construct () {
> > $this->myself = $this;
> > }
> > }
> >
> > $TestObj = new TestClass ();
> >
> > if ( $TestObj->myself == $TestObj ) {
> > echo "They are same.\n";
> > }
> >
> > ?>
> >
> > Gives me a "Fatal error: Nesting level too deep - recursive dependency?"
> > on line #13: if ( $TestObj->myself == ...)
> >
> > Could this be a PHP bug or I'm doing something wrong?
> >
> > FYI:
> >
> > PHP Version 5.0.2
> > PHP API 20031224
> > PHP Extension 20040412
> > Zend Extension 220040412
> > Server API Apache 2.0 Handler
>
> --
> 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] Nesting level too deep - recursive dependency?
That's a really elegant solution... I'm up for trying that out. Remember to do != too :) Jevon - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Greg Beaver" <[EMAIL PROTECTED]>; "Jevon Wright" <[EMAIL PROTECTED]> Cc: "Benj Carson" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, October 20, 2004 6:46 AM Subject: Re: [PHP-DEV] Nesting level too deep - recursive dependency? > At 10:10 AM 10/19/2004 -0400, Greg Beaver wrote: > >Jevon Wright wrote: > >>I first stumbled upon this problem in one of the RCs for PHP 5, but at the > >>time I thought I was at fault... > >>Consider the documentation at > >>http://www.php.net/manual/en/language.oop5.object-comparison.php : the > >>documentation is a little vague, but it does say "Two object instances are > >>equal if they have the same attributes and values, and are instances of the > >>same class." Thus explaining the recursive loop... > >>Maybe write a big flashing note in the documentation instead about this > >>trap? > > > >Better, if two values satisfy ===, they are clearly ==. I would imagine > >it would not be expensive to simply do a === check before doing the == > >check in the engine? > > That might actually be a good idea. It would definitely solve some > headaches and be faster. > Does anyone object to me doing this? > > 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] suggestion: empty() with infinite parameters like isset()
How about anyempty($var1, $var2, $var3, ...) ? Jevon - Original Message - From: "Ron Korving" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, October 21, 2004 12:21 AM Subject: Re: [PHP-DEV] suggestion: empty() with infinite parameters like isset() > Maybe it was a bad example. Writing "data missing" I was thinking that at > least one variable should be set. > > Ron > > "Derick Rethans" <[EMAIL PROTECTED]> schreef in bericht > news:[EMAIL PROTECTED] > > On Wed, 20 Oct 2004, Ron Korving wrote: > > > > > Okay, I don't wanna make remarks that may have already been made > earlier, > > > but I think it should be "all should be empty", because it works exactly > the > > > same for isset(), and apparently, a decision was made to give isset() > that > > > feature. > > > > Right, but then your example would already no longer have worked: > > > > if (empty($var1, $var2, $var3)) echo "data missing"; > > > > so there is no point in adding it like that. > > > > 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 Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: [sqlite] PHP5 && SQLite3
Probably covered by your "engine" point: please get __toString() to work
properly with string concatenation and casting :)
Thanks,
Jevon
- Original Message -
From: "Andi Gutmans" <[EMAIL PROTECTED]>
To: "Greg Beaver" <[EMAIL PROTECTED]>
Cc: "internals" <[EMAIL PROTECTED]>
Sent: Friday, October 22, 2004 5:55 AM
Subject: Re: [PHP-DEV] Re: [sqlite] PHP5 && SQLite3
> I think this is something which belongs to user-land. I don't see a reason
> not to implement it in that way.
>
> Andi
>
> At 11:04 AM 10/21/2004 -0400, Greg Beaver wrote:
> >f) if at all possible, It would be very good if the exception signature
> >could be modified to accept another exception object as a third
> >parameter. Why?
> >
> >try {
> > // blah
> >} catch (SubException $e) {
> > throw new ParentException('message', CODE, $e);
> >}
> >.
> >class ParentException extends Exception
> >{
> > function __toString()
> > {
> > $current = parent::__toString();
> > if ($arr = $this->getCauses()) {
> > $current .= "\nThis exception caused by:\n"
> > foreach ($arr as $e) {
> > $current .= $e->__toString();
> > }
> > }
> > return $current;
> > }
> >}
> >
> >This will allow chaining of exceptions, as they can be designed to do
> >already, but in a simple, standardized way. It would not need to affect
> >uncaught exceptions, but __toString() could take advantage of getCauses()
> >to spit out this information.
> >
> >see pear-core/PEAR/Exception.php for userland example. I'd like to
remove
> >as much logic from this class as humanly possible, and concentrate its
> >efforts on display of information only.
> >
> >If this sounds like a worthy effort, should I open a feature request?
> >
> >Thanks,
> >Greg
>
> --
> 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] Studlycaps and MySQLi
I'm in the "change it to be consistent" boat - Original Message - From: "Andi Gutmans" <[EMAIL PROTECTED]> To: "Rasmus Lerdorf" <[EMAIL PROTECTED]>; "Georg Richter" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]>; "George Schlossnagle" <[EMAIL PROTECTED]>; "Edin Kadribasic" <[EMAIL PROTECTED]>; "Marcus Boerger" <[EMAIL PROTECTED]>; "PHP Internals" <[EMAIL PROTECTED]> Sent: Wednesday, March 24, 2004 9:30 AM Subject: Re: [PHP-DEV] Studlycaps and MySQLi > ... > Huh? Now you're really going to confuse people. You can always have RC2 and > more. As it is there will be enough meat to have an RC2 after bug fixes > (things which weren't discovered before more people started testing the RC). > We decided on studlyCaps a while ago and I wasn't aware people here didn't > apply this decision. Anyway, we are and where in a feature freeze but as I > said, I didn't realize people didn't apply that decision. If there's a > consensus we can stay with the way things are but I think it's dumb to do > so just because an RC has been out for a few days. If we release an RC2 > quickly it will be barely noticed. We will regret the inconsistency forever > if we don't take care of it (which we already do with the functional part > of PHP). If all of you prefer this inconsistency then so be it. > Andi -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] __toString() with cast is broken in php5 RC1
Can you add a default __toString() for all objects (which don't extend or
implement a __toString()) then? Because at least then we could use $str =
$anyobj->__toString(). Otherwise I don't think __toString() has any real
functionality, except for print and echo...
Jevon
- Original Message -
From: "Marcus Boerger" <[EMAIL PROTECTED]>
To: "David Giffin" <[EMAIL PROTECTED]>
Cc: "Marcus Boerger" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Friday, April 02, 2004 12:27 PM
Subject: Re: [PHP-DEV] __toString() with cast is broken in php5 RC1
> Hello David,
>
> generally the idea is to change this back. But i don't think we will
> be able to solve the related problems before PHP 5.1.
>
> marcus
>
> Friday, April 2, 2004, 2:03:38 AM, you wrote:
>
>
> > Hi Marcus,
>
> > Is this going to change back? The php5 documentation on the zend site
> > shows that both casting and print/echo should work.
>
> > I guess people could use the output buffering methods to get the print
> > data for the time being. A not so happy work around :(
>
> > Thanks again,
> > David
>
>
> > On Fri, 2 Apr 2004, Marcus Boerger wrote:
>
> >> Hello David,
> >>
> >> that's correct. See the NEWS file, 3rd entry:
> >>
> >> 18 March 2004, PHP 5 Release Candidate 1
> >> - Fixed numerous bugs with the just-in-time auto-global initialization,
that
> >> could cause $_SERVER, $argv/$argc and other variables not to work
properly.
> >> (Zeev)
> >> - Fixed data corruption with constant assignments to object properties.
(Zeev)
> >> - Changed __toString() to be called automatically only with print and
echo
> >> statements. (Andi)
> >>
> >> Friday, April 2, 2004, 1:13:28 AM, you wrote:
> >>
> >>
> >> > Hi There,
> >>
> >> > I just got a chance tp update to PHP5 RC1 and noticed that some
things
> >> > have changed for the __toString method. It seems that it it only
getting
> >> > called when the object is printed or echo. Casting the object to a
string
> >> > returns the Object #. Here is an example:
> >>
> >>
> >>
> >> > The Script:
> >>
> >> > >>
> >> > class obj
> >> > {
> >> > function __toString()
> >> > {
> >> > return "yo!!\n";
> >> > }
> >> > }
> >>
> >> > $obj = new obj();
> >> > print_r($obj);
> >>
> >> > $test = (string) $obj;
> >>
> >> > print $test;
> >> > print $obj;
> >>
> >> ?>>
> >>
> >> > - Produces:
> >>
> >> > obj Object
> >> > (
> >> > )
> >> > Object id #1yo!!
>
> --
> 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] Exceptions and Errors
> Your example is interesting. It shows an error that would be continuable > from an engine's point of view but not from the script's point of view. It > shows that there should not be any possibility to recover from exceptions > at the exact spot where the exception was thrown - anyway somthing that > violates the general exception idea (see Stanislav's mail on local stack > corruption...). Java has the concept of an "Error" (extended from Throwable which is extended to be Exception too) which "indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions." Perhaps normal E_ERROR => Exception, and totally fatal errors => Error. You can catch Errors too, but it's specifically said that you really shouldn't try. Jevon -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Exceptions and Errors
> Guys, I'm am not for forcing people to use exceptions. I agree that we
> should make PHP another Java exceptions from hell (especially with their
> exception declarations in function prototypes which is horrible). I'm just
> saying, that some extensions might benefit from exceptions and the
> extension author should be allowed to choose (as long as he doesn't break
BC).
But the exception declarations ensure that you don't accidentally catch an
Exception in the wrong place, eg.
function add($amount)
{
add_money($amount) and log() or throw exception;
}
function move($amount)
{
$from->add(-$amount);
# It is *not* obvious here that this can fail and execution
# might stop here! Very dangerous!
$to->add($amount);
}
function transactions()
{
foreach ($transaction)
try { move($transaction->amount); } catch ...
}
You'd have to go function move($amount) throws SomeException, forcing
the developer to handle Exceptions at the soonest possible point...
(I'm a fan of it.)
Jevon
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
