Re: [PHP-DEV] DVCS
On Thu, Apr 28, 2011 at 4:10 AM, Ben Schmidt wrote: > Hi! > > I realise that at least for now, PHP is sticking with SVN. No problems. > > However...I find it much easier to work in Mercurial to put together > patches, find bugs, etc.. And in fact, I find SVN really awkward--I was > on the verge of switching back to CVS when DVCSes such as Mercurial and > Git became popular. I would put in a vote for Mercurial if PHP decides > to move to a DVCS. Mercurial is more similar to CVS/SVN in its command > set than other DVCSes, is easy and friendly to use, generally does what > you would expect, makes it pretty hard to shoot yourself in the foot, > and includes good Windows support. Operating with the Mozilla and Vim > Mercurial repositories is a lovely experience, and I'd love to add PHP > to the list of projects I follow this way. > > However, pushing the team towards a DVCS is not what I'm writing for. > Certainly not to push for a particular one. > > I'd just like to be able to use my tool of choice (Mercurial) locally. > Would it be possible to set up a Mercurial mirror of the SVN repo on, > say, bitbucket.org, so I could pull from there? Alternatively, I can > access a git repo somewhere like github.com (I found > https://github.com/php/php-src but the last activity seems to be about 9 > months ago--is it dead? are there any plans to revive it?). Of course, > as a last resort, I could just access SVN using Mercurial. However, it > may result in a lower server load if PHP can provide a mirror somewhere, > updated by a commit hook or daily cron job or something, rather than me > (and potentially many others, as DVCSes become even more popular) > accessing SVN directly. > > Any possibility? (I'm happy to help, if I can be given appropriate > access to resources to do so.) > > Ben. > > > anybody out there, who didn't tried github yet, should really do it. and you can use your svn client to interact with your github repo, if you didn't feel the need to learn git. https://github.com/blog/644-subversion-write-support Tyrael
Re: [PHP-DEV] DVCS
dukeofgaming wrote: http://programmers.stackexchange.com/questions/35074/im-a-subversion-geek-why-i-should-consider-or-not-consider-mercurial-or-git-or/35080#35080 So, I don't want to make debate here of wether centralized is better than distributed (because the point is moot), but I think its not a good situation for the community to have a previously open door to DVCSs now closed. Having been battling with various projects that have decided that 'git is good' or 'hg is best' ... I've been trying to live in the new world and failing. That link is looking like a nice CURRENT overview of the situation although things are still changing mainly for the good. My problem until recently was that 'subrepo' management in DVCS has always been playing catchup. Yesterday for the first time I checked out a 'super-project' matching one of the composite builds provided on an original CVS repo! Still not fully integrated into Eclipse, but hopefully even that will come with time. But now I can 'clone' the half dozen different builds and manage them in parallel with both github and bitbucket 'masters'. I'm using Mercurial and TortoiseHg which almost work transparently between Linux and Windows, and with hg-git access to the 'git is good' projects is also transparent even on windows. Next step this weekend IS to tidy up the SVN setup so that I have the PHP code locally mirrored as well -- 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// Firebird - http://www.firebirdsql.org/index.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hi! http://wiki.php.net/rfc/returntypehint for the upcoming 5.4 release, I think it would be extremely useful, even without the scalar stuff. Personally, I see even less point in having strict return typing (please stop using "hint" terminology, it confuses the whole matter, it's not "hint" if it describes mandatory restriction on the data) than strict argument typing. The RFC doesn't explain it either beyond "here how you can have some nice errors". But why would I want to see these errors? How they would make anything easier or better? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Am 28.04.2011 10:23, schrieb Stas Malyshev:
> But why would I want to see these errors?
> How they would make anything easier or better?
to find problems before your users?
i do not know what you want, but i want with
"error_reporting = E_ALL | E_STRICT" get noticed if
something possible is unclean
it is the same as for functions - so what is the difference
between the following? the first one can get a empty string
and will not notice you and ignore the foreach
the second one will produce an error if empty string is given
while an empty array would be accepted
function bla($arr)
{
if(!empty($arr))
{
foreach($arr)
{
}
}
}
function bla(array $arr)
{
if(!empty($arr))
{
foreach($arr)
{
}
}
}
signature.asc
Description: OpenPGP digital signature
Re: [PHP-DEV] [RFC] Return type-hint
Hi! to find problems before your users? Sorry, this doesn't say much. It's a generic, of course we agree it's good to find bugs sooner rather than later. The question is why would that specific thing that is being proposed help - in which specific way? the second one will produce an error if empty string is given while an empty array would be accepted And it is better because?.. Also please note we are discussing strict return typing. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 10:23 AM, Stas Malyshev wrote: > Hi! > > http://wiki.php.net/rfc/returntypehint >>> >> for the upcoming 5.4 release, I think it would be extremely useful, even >> without the scalar stuff. >> > > > Personally, I see even less point in having strict return typing (please > stop using "hint" terminology, it confuses the whole matter, it's not "hint" > if it describes mandatory restriction on the data) than strict argument > typing. The RFC doesn't explain it either beyond "here how you can have some > nice errors". > But why would I want to see these errors? How they would make anything > easier or better? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > do you aware that without the scalar support, the return type hinting would behave just as "strict" as the argument type hinting is currently. http://php.net/manual/en/language.oop5.typehinting.php so maybe type hinting wasn't a good name at the first place, but we should be consistent with the current naming convention. Tyrael
Re: [PHP-DEV] Unmaintained SAPIs
All right ;-) Johannes: Thanks for details about lighhtpd's internals. Julien.P 2011/4/27 Johannes Schlüter > On Wed, 2011-04-27 at 15:36 +0200, Julien Pauli wrote: > > I'm +1 with that list. > > > > I'd like to have some time to work on a lighttpd sapi if possible > > (haven't seen lighttpd API yet). If someone got the same idea, just > > tell it... > > lighty's API for that is FastCGI. There is an native API, but plugging > in PHP there would be bad in regards to lighty's event-based > architecture. > > > What about apache2filter SAPI ? > > What what? I didn't here from people who are using or maintaining it ... > so it's on the "i don't know" list. > > johannes > > > Julien.P > > > > 2011/4/24 Pierre Joye > > 2011/4/24 Rasmus Lerdorf : > > > On 4/24/11 4:41 AM, Pierre Joye wrote: > > >> > > >> hi, > > >> > > >> Do we really need apache 1.x SAPIs? > > >> > > >> ISAPI should be kept in (was decided so by the 5.3.0 > > release time), it > > >> is still used and works for users with custom versions. A > > new version > > >> may come as well, as part of one of some features I'm > > working on. > > > > > > Your argument for ISAPI applies exactly to Apache 1 as well. > > > > > > Not that it is so important (does not hurt anyone to keep it > > in) but > > apache 1.x is dead, not IIS :). > > > > Cheers, > > -- > > Pierre > > > > @pierrejoye | http://blog.thepimp.net | http://www.libgd.org > > > > -- > > > > > > PHP Internals - PHP Runtime Development Mailing List > > To unsubscribe, visit: http://www.php.net/unsub.php > > > > > > > > >
Re: [PHP-DEV] [RFC] Return type-hint
> > > > The RFC doesn't explain it either beyond "here how you can have some nice > errors". > But why would I want to see these errors? How they would make anything > easier or better? > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > maybe we should improve on the rfc. I see many advantages of the introduction of return type hinting. - you can guarantee that your methods returns only what is explicitly stated (or else it blows up, the same as for arguments) - it can save you from having to define the return type in phpdoc, your code can define it's behavior - I think maybe the language itself could use that information, for performance, etc. improvements (we know that the return value will be created runtime, but we can throw it away if it doesn't match the return type or something), maybe we can use that information to throw errors on compile time if we find a non runtime decided return value which doesn't match with the return type. I'm sure that others have and will come up with more use cases. Tyrael
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 01:35:00AM -0700, Stas Malyshev wrote:
> Hi!
>
> >to find problems before your users?
>
> Sorry, this doesn't say much. It's a generic, of course we agree it's
> good to find bugs sooner rather than later. The question is why would
> that specific thing that is being proposed help - in which specific way?
It would mean that the code that follows could benefit from the PHP run
time checking the return type -- at the point of return. Thus eliminating
following errors where the user does not check, eg:
function array foo() { }
$ret = foo();
foreach($ret as $val)
I must admit that this is much less useful than checking of argument types
going into functions, where the writer of the function (part of a libarary
perhaps)
does not trust the function user to get validation/... right.
But this is another discussion.
The other way in that this could be very helpful is with run time optimisation,
especially
for things like HipHop - think of the optimisation that it could make if it knew
the real return type, eg:
function int bar() { ... }
(The argument about argument types is even more so here.)
> >the second one will produce an error if empty string is given
> >while an empty array would be accepted
>
> And it is better because?..
> Also please note we are discussing strict return typing.
I am also mindful that the proposed syntax does not allow description
of functions that return more than one type; where they return something
to indicate a failure (or end) - typically FALSE or NULL. So maybe something
like
the following could cope with them:
function (array | bool) baz() { ... }
or even:
function (array | false) baz() { ... }
I can see that some may prefer commas:
function (array, false) baz() { ... }
although, to me, that looks like a list - I prefer vertical bar.
HipHop would be able to optimise things like:
if( ($ret = baz()) !== FALSE ) {
...
}
[**] https://github.com/facebook/hiphop-php/wiki/
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 10:39:55AM +0200, Ferenc Kovacs wrote: > do you aware that without the scalar support, the return type hinting would > behave just as "strict" as the argument type hinting is currently. > http://php.net/manual/en/language.oop5.typehinting.php > > so maybe type hinting wasn't a good name at the first place, but we should > be consistent with the current naming convention. Yes, it was a poor choice of words. I think that it should be renamed 'type checking' with a transition note, eg: Type checking (formerly called type hinting) -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On 04/28/2011 01:58 AM, Alain Williams wrote:
On Thu, Apr 28, 2011 at 01:35:00AM -0700, Stas Malyshev wrote:
Hi!
to find problems before your users?
Sorry, this doesn't say much. It's a generic, of course we agree it's
good to find bugs sooner rather than later. The question is why would
that specific thing that is being proposed help - in which specific way?
It would mean that the code that follows could benefit from the PHP run
time checking the return type -- at the point of return. Thus eliminating
following errors where the user does not check, eg:
function array foo() { }
$ret = foo();
foreach($ret as $val)
I don't see this being useful at all. All you are doing is duplicating a
runtime warning. We can't possibly know at compile-time whether this
return value is an array or not, so there is no compile-time benefit.
eg.
function array foo() {
$ret = bar();
return $ret;
}
So in this case we get a warning on the return and then another warning
on the foreach(). We have not gained anything except an extra warning
for the same problem in this code example.
And this gets even worse if you start doing scalar return type checking.
Now you are adding warnings for types that are safely interchangeable.
-Rasmus
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 02:43:36AM -0700, Rasmus Lerdorf wrote:
> > function array foo() { }
> >
> > $ret = foo();
> > foreach($ret as $val)
> >
>
> I don't see this being useful at all. All you are doing is duplicating a
> runtime warning. We can't possibly know at compile-time whether this
> return value is an array or not, so there is no compile-time benefit.
The check is not done where foo() is called but within foo() itself, to ensure
that it only returns an array.
There will also be advantages for HipHop which can afford to spend the time to
do static analysis of code -- I know that HipHop is not your baby
but you now need to recognise that there is more than one PHP implementation
and features that may not had much advantage with Zend may be useful elsewhere.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Bug in zend_hash_init()
Hi,
In function zend_hash_init() when allocate no persistent memory (if flag
persistent is 0) for arBuckets element of struct HashTable and virtual
memory is over, the function always returns SUCCESS
Code:
if (persistent) {
tmp = (Bucket **) calloc(ht->nTableSize, sizeof(Bucket *));
if (!tmp) {
return FAILURE;
}
ht->arBuckets = tmp;
} else {
// No checking on return value?
tmp = (Bucket **) ecalloc_rel(ht->nTableSize, sizeof(Bucket *));
if (tmp) {
ht->arBuckets = tmp;
}
}
diff -Nur php-src-5.3.orig//Zend/zend_hash.c php-src-5.3/Zend/zend_hash.c
--- php-src-5.3.orig//Zend/zend_hash.c 2011-04-28 17:14:31.003354396 +0700
+++ php-src-5.3/Zend/zend_hash.c 2011-04-28 17:15:42.081164359 +0700
@@ -175,9 +175,10 @@
ht->arBuckets = tmp;
} else {
tmp = (Bucket **) ecalloc_rel(ht->nTableSize, sizeof(Bucket *));
- if (tmp) {
- ht->arBuckets = tmp;
+ if (!tmp) {
+ return FAILURE;
}
+ ht->arBuckets = tmp;
}
return SUCCESS;
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Bug in zend_hash_init()
On 04/28/2011 02:53 PM, Anton Dobkin wrote: // No checking on return value? Yes, it doesn't check for NULL. See ecalloc() sources in Zend/zend_alloc.c around line 2434 to see why. -- Wbr, Antony Dovgal --- http://pinba.org - realtime statistics for PHP -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hey All,
I'm really interested on this topic.
What would be the result of this?
function Foo foo($something) {
if ( $something ) {
return new Foo;
}
// no return implies return null
}
How do you force to return a Type with null allowed?
Martin Scotta
On Thu, Apr 28, 2011 at 6:59 AM, Alain Williams wrote:
> On Thu, Apr 28, 2011 at 02:43:36AM -0700, Rasmus Lerdorf wrote:
>
> > > function array foo() { }
> > >
> > > $ret = foo();
> > > foreach($ret as $val)
> > >
> >
> > I don't see this being useful at all. All you are doing is duplicating a
> > runtime warning. We can't possibly know at compile-time whether this
> > return value is an array or not, so there is no compile-time benefit.
>
> The check is not done where foo() is called but within foo() itself, to
> ensure
> that it only returns an array.
>
> There will also be advantages for HipHop which can afford to spend the time
> to
> do static analysis of code -- I know that HipHop is not your baby
> but you now need to recognise that there is more than one PHP
> implementation
> and features that may not had much advantage with Zend may be useful
> elsewhere.
>
> --
> Alain Williams
> Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
> Lecturer.
> +44 (0) 787 668 0256 http://www.phcomp.co.uk/
> Parliament Hill Computers Ltd. Registration Information:
> http://www.phcomp.co.uk/contact.php
> #include
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 10:30:43AM -0300, Martin Scotta wrote:
> Hey All,
> I'm really interested on this topic.
>
> What would be the result of this?
>
> function Foo foo($something) {
> if ( $something ) {
> return new Foo;
> }
> // no return implies return null
> }
>
> How do you force to return a Type with null allowed?
That is why I suggested, in addition to the above, a syntax like:
function (Foo | NULL) foo($something) {
to be able to specify where a function can return more than one type.
The 'extra' types/values are nearly always either NULL or FALSE.
Regards
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
FWIW, I don't see much point in this either, as far as error reporting is concerned. I think type checking for parameters can provide cheap and useful validation, as parameters passed in are outside the function's control. But return values? They are within the function's control, and in most functions are not hard to ensure are correct without needing runtime checking. If PHP were compiled, not interpreted, i.e. less dynamic, there could be some benefits, as compile-time optimisations could perhaps be built in, and validations skipped if they were provably unnecessary. But that's not going to happen any time soon, as far as I'm aware. So the only real benefit is that they could make code slightly self-documenting. But since they would still be optional, they don't help much: the coder might as well take up the option to write some more useful documentation. Also, PHP has so many conventions such as returning false on error that don't fit cleanly into the model, that it's awkward. I'd love to see those problems solved neatly for function arguments before extending anything to function return types. I don't think it would do any harm though, so don't see any argument against it. I just don't think there's a good argument for it. Ben. On 28/04/11 6:23 PM, Stas Malyshev wrote: Hi! http://wiki.php.net/rfc/returntypehint for the upcoming 5.4 release, I think it would be extremely useful, even without the scalar stuff. Personally, I see even less point in having strict return typing (please stop using "hint" terminology, it confuses the whole matter, it's not "hint" if it describes mandatory restriction on the data) than strict argument typing. The RFC doesn't explain it either beyond "here how you can have some nice errors". But why would I want to see these errors? How they would make anything easier or better? -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Fri, Apr 29, 2011 at 01:58:02AM +1000, Ben Schmidt wrote: > If PHP were compiled, not interpreted, i.e. less dynamic, there could be > some benefits, as compile-time optimisations could perhaps be built in, and > validations skipped if they were provably unnecessary. But that's not going > to happen any time soon, as far as I'm aware. It has already happened: https://github.com/facebook/hiphop-php/wiki/ It might also be useful for reflection. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On 29/04/11 2:10 AM, Alain Williams wrote: On Fri, Apr 29, 2011 at 01:58:02AM +1000, Ben Schmidt wrote: If PHP were compiled, not interpreted, i.e. less dynamic, there could be some benefits, as compile-time optimisations could perhaps be built in, and validations skipped if they were provably unnecessary. But that's not going to happen any time soon, as far as I'm aware. It has already happened: https://github.com/facebook/hiphop-php/wiki/ It might also be useful for reflection. *Hastily retracts comment.* That is very cool. I should give it a try. I also see the value of such type checking for such a use case, obviously. I guess there's a reason for it after all. I'd still like to see something neat to handle more than just named classes, though, e.g. scalars, and things like "false on error" for return values. Ben. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Fri, Apr 29, 2011 at 02:38:31AM +1000, Ben Schmidt wrote:
> I also see the value of such type checking for such a use case, obviously.
>
> I guess there's a reason for it after all.
>
> I'd still like to see something neat to handle more than just named
> classes, though, e.g. scalars, and things like "false on error" for return
> values.
That is why I suggested, in addition to the above, a syntax like:
function (Foo | NULL) foo($something) {
to be able to specify where a function can return more than one type.
The 'extra' types/values are nearly always either NULL or FALSE.
I agree that being able to specify as types: array, scalar, int, string, ...
would be useful for a compiler but prob have little value for Zend - other than
documentation/reflection.
--
Alain Williams
Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT
Lecturer.
+44 (0) 787 668 0256 http://www.phcomp.co.uk/
Parliament Hill Computers Ltd. Registration Information:
http://www.phcomp.co.uk/contact.php
#include
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Martin Scotta On Thu, Apr 28, 2011 at 12:58 PM, Ben Schmidt wrote: > FWIW, I don't see much point in this either, as far as error reporting is > concerned. I think type checking for parameters can provide cheap and useful > validation, as parameters passed in are outside the function's control. But > return values? They are within the function's control, and in most functions > are not hard to ensure are correct without needing runtime checking. > > If PHP were compiled, not interpreted, i.e. less dynamic, there could be > some benefits, as compile-time optimisations could perhaps be built in, and > validations skipped if they were provably unnecessary. But that's not going > to happen any time soon, as far as I'm aware. > Yes, PHP is interpreted, but remember that PHP has its own "compile-time". An option could be to use the "hints" only for compile purposes, but then at runtime the core can behave as it's today. > > So the only real benefit is that they could make code slightly > self-documenting. But since they would still be optional, they don't help > much: the coder might as well take up the option to write some more useful > documentation. > > Also, PHP has so many conventions such as returning false on error that > don't fit cleanly into the model, that it's awkward. I'd love to see those > problems solved neatly for function arguments before extending anything to > function return types. > > I don't think it would do any harm though, so don't see any argument > against it. I just don't think there's a good argument for it. > Ben. > > > > > On 28/04/11 6:23 PM, Stas Malyshev wrote: > >> Hi! >> >> http://wiki.php.net/rfc/returntypehint >>> for the upcoming 5.4 release, I think it would be extremely useful, even >>> without the scalar stuff. >>> >> >> >> Personally, I see even less point in having strict return typing (please >> stop >> using "hint" terminology, it confuses the whole matter, it's not "hint" if >> it >> describes mandatory restriction on the data) than strict argument typing. >> The RFC >> doesn't explain it either beyond "here how you can have some nice errors". >> But why would I want to see these errors? How they would make anything >> easier or >> better? >> > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
Re: [PHP-DEV] [RFC] Return type-hint
Hi! There will also be advantages for HipHop which can afford to spend the time to do static analysis of code -- I know that HipHop is not your baby but you now need to recognise that there is more than one PHP implementation and features that may not had much advantage with Zend may be useful elsewhere. If you want a statically typed language, there are tons of these on the market. However, unless you change PHP into another - statically typed - language, I do not see how it really helps. What you talking about here is creating a dialect of PHP targeted for statically-compiled environment. I personally see it a bit pointless, since there are already many perfectly good static languages on the market, with excellent compilers and environments - so why not use any of these? But that shouldn't deter you - my personal opinion is just that, if you want to create your own static PHP, go ahead. But I do not believe doing it in little tweaks would work - if you want reliable typing, you need it everywhere. However, I seriously doubt PHP as a whole would benefit from it. Most uses of PHP are very dynamic and would not yield serious benefits from introducing static typing constructs beyond very specific cases in very specific environments. Changing the whole language to benefit these narrow scenarios does not seem beneficial to me. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hi! I see many advantages of the introduction of return type hinting. - you can guarantee that your methods returns only what is explicitly stated (or else it blows up, the same as for arguments) You can't, because function resolution happens in runtime, so the only point you know what the function called "foo" returns is the moment where you're already calling it, not a moment before. - it can save you from having to define the return type in phpdoc, your code can define it's behavior Why I need being "saved" from documenting my code properly? Anyway, the function code defines the behavior, declaration of return type just ensures function would fail in runtime if your code tries to return unexpected data - but how is it helpful? The client of this function doesn't even know that before actually calling it! - I think maybe the language itself could use that information, for performance, etc. improvements (we know that the return value will be That would need static compile-time binding of functions, which implies static binding of includes, etc. - basically, compiling PHP code as a whole in one monolitic application. created runtime, but we can throw it away if it doesn't match the return type or something), maybe we can use that information to throw errors on compile time if we find a non runtime decided return value which doesn't match with the return type. Sorry, what is "non runtime decided return value"? And how is "compile time" different from "runtime" in your opinion - when exactly that "compile time" happens? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] A patch for APC harklinks problem
On 04/27/2011 08:18 PM, 陈磊 wrote: > The bug url: > http://pecl.php.net/bugs/bug.php?id=22673 I would also suggest mailing apc-dev @ lists.php.net (even though there is likely to be a big overlap in readership with internals@). Chris > > BRs, > Chen Lei > > 于 2011-4-27 18:34, Pierre Joye 写道: >> hi, >> >> Please report bug and patches to the pecl.php.net/apc bug tracker. >> >> Thanks for your work, >> >> Cheers, >> >> 2011/4/27 陈磊: >>> Hi, >>> >>> I come from sae team of sina. We meet with a problem of APC harklinks >>> mentioned in the buglist of PHP and APC long time ago. >>> >>> The key word __FILE__ is a magic constants, and it is generated after the >>> php source code is compiled. >>> When the APC is used as a php extension for performence reason, the >>> compiling and executing are independent. >>> So, there are some problems. Please refer to the bug links: >>> http://bugs.php.net/bug.php?id=45421 >>> http://pecl.php.net/bugs/bug.php?id=14055&thanks=3 >>> >>> I thinks there shoule be a feature in PHP Runtime to get the current >>> executed file name at execute-time(not compile-time). >>> apc_auto_hardlinks_for_php_5.3.5.diff is a patch for PHP 5.3.5, and the >>> patch is to add a new key word "executed_filename". >>> >>> When the following code is running: >>> >> echo executed_filename; >>> ?> >>> >>> In PHP Runtime, zend_get_executed_filename() is called to returne the >>> current executed file name and being displayed. >>> >>> To fixed the APC hardlinks problem, the other patch >>> auto_hardlinks_for_apc_3.1.6.diff must be used. The filename of >>> opcode array should be updated when both setting and getting get opcode >>> array to caches in APC. >>> >>> Hope the php patch should be reviewed and php runime will provide the way to >>> get current executed file name at >>> execute-time in the future. >>> >>> Thanks so much. >>> >>> BRs, >>> Chen Lei >>> simpcl2...@gmail.com >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >> >> > -- Email: christopher.jo...@oracle.com Tel: +1 650 506 8630 Blog: http://blogs.oracle.com/opal/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Here's my issue: We're borrowing a feature from strongly typed languages and forcing it on a loosely typed language. I'm fine with this, if we're true to the concept. In a regular language, if you type something to return an object of type Foo, you might still get back null, and appropriately need to check for this. NULL is a perfectly valid state for an object. The objection I'm hearing to this is that because in PHP, null is a value and not a state, and since variables don't have types (values do), null should be an explicitly specified hint. To me, this is a nuclear bomb waiting to go off. If we allow the syntax described earlier (Foo | Bar | Null) we're violating the concept entirely, and there's no point in even having the feature. If a developer can type hint a function in such a way that you don't actually know what you're getting besides a subset of types, this has the exact opposite effect that return hinting is supposed to have. Now, I have to check for what type the value returned is, on top of null. Why even use return hinting? The other suggestion I've heard is to only allow for Object || Null, but this too seems ridiculous. The idea would be that if you're in a situation where you can't feasibly return the specified object, you should throw an exception. So now your code is going to be riddled with things like ObjectIsNullException, or generic handlers that don't know what to do besides go "OOPS!" when this happens. OR, you force default values down your object's throats. This is bad when the object you're using is volatile, and writes to a database or something. The complain is that implicitly allowing null returns means you have to check for null even if you're expecting an object. But *you have to do this anyway* if you're not hinting. +1 for return type hinting -1 for explicitly specifying null -1 for specifying multiple return types On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote: > Hi! > >> There will also be advantages for HipHop which can afford to spend the time >> to >> do static analysis of code -- I know that HipHop is not your baby >> but you now need to recognise that there is more than one PHP implementation >> and features that may not had much advantage with Zend may be useful >> elsewhere. > > If you want a statically typed language, there are tons of these on the > market. However, unless you change PHP into another - statically typed - > language, I do not see how it really helps. > What you talking about here is creating a dialect of PHP targeted for > statically-compiled environment. I personally see it a bit pointless, since > there are already many perfectly good static languages on the market, with > excellent compilers and environments - so why not use any of these? But that > shouldn't deter you - my personal opinion is just that, if you want to create > your own static PHP, go ahead. But I do not believe doing it in little tweaks > would work - if you want reliable typing, you need it everywhere. > > However, I seriously doubt PHP as a whole would benefit from it. Most uses of > PHP are very dynamic and would not yield serious benefits from introducing > static typing constructs beyond very specific cases in very specific > environments. Changing the whole language to benefit these narrow scenarios > does not seem beneficial to me. > -- > Stanislav Malyshev, Software Architect > SugarCRM: http://www.sugarcrm.com/ > (408)454-6900 ext. 227 > > -- > 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] Return type-hint
On Thu, Apr 28, 2011 at 7:45 PM, Stas Malyshev wrote: > Hi! > > > I see many advantages of the introduction of return type hinting. >> - you can guarantee that your methods returns only what is explicitly >> stated (or else it blows up, the same as for arguments) >> > > You can't, because function resolution happens in runtime, so the only > point you know what the function called "foo" returns is the moment where > you're already calling it, not a moment before. > > it's the same as for the current argument type hinting. you can access that information via Reflection http://hu2.php.net/manual/en/reflectionparameter.getclass.php > > - it can save you from having to define the return type in phpdoc, your >> code can define it's behavior >> > > Why I need being "saved" from documenting my code properly? Anyway, the > function code defines the behavior, declaration of return type just ensures > function would fail in runtime if your code tries to return unexpected data > - but how is it helpful? The client of this function doesn't even know that > before actually calling it! why did we added ppp if people can define in the documentation(or in the method name :/) that which method is public and which isn't > > > - I think maybe the language itself could use that information, for >> performance, etc. improvements (we know that the return value will be >> > > That would need static compile-time binding of functions, which implies > static binding of includes, etc. - basically, compiling PHP code as a whole > in one monolitic application. I see > > > created runtime, but we can throw it away if it doesn't match the return >> type or something), maybe we can use that information to throw errors on >> compile time if we find a non runtime decided return value which doesn't >> match with the return type. >> > > Sorry, what is "non runtime decided return value"? And how is "compile > time" different from "runtime" in your opinion - when exactly that "compile > time" happens? > > Just throwing ideas around. when we parse the php code to opcode, the interpreter could use the typehint information to catch trivial cases(eg. we cannot tell that return $foo is valid, but we can tell that return FALSE is not valid if the typehint doesn't specify that). I hope this clears that up. Tyrael
Re: [PHP-DEV] [RFC] Return type-hint
Martin Scotta
On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson wrote:
> Here's my issue:
>
> We're borrowing a feature from strongly typed languages and forcing it on a
> loosely typed language. I'm fine with this, if we're true to the concept.
>
> In a regular language, if you type something to return an object of type
> Foo, you might still get back null, and appropriately need to check for
> this. NULL is a perfectly valid state for an object.
>
Probably core folks may know how this works better than me but I think that
null is not an object, scalar or anything at all. It just means
the absence of value.
That's why I always thought that NULL meant "no value".
function foo(Foo $f1, Foo $f2=null) {
// $f1 can't be null
// $f2 can be null
}
> The objection I'm hearing to this is that because in PHP, null is a value
> and not a state, and since variables don't have types (values do), null
> should be an explicitly specified hint.
>
> To me, this is a nuclear bomb waiting to go off. If we allow the syntax
> described earlier (Foo | Bar | Null) we're violating the concept entirely,
> and there's no point in even having the feature. If a developer can type
> hint a function in such a way that you don't actually know what you're
> getting besides a subset of types, this has the exact opposite effect that
> return hinting is supposed to have. Now, I have to check for what type the
> value returned is, on top of null. Why even use return hinting?
>
> The other suggestion I've heard is to only allow for Object || Null, but
> this too seems ridiculous. The idea would be that if you're in a situation
> where you can't feasibly return the specified object, you should throw an
> exception. So now your code is going to be riddled with things like
> ObjectIsNullException, or generic handlers that don't know what to do
> besides go "OOPS!" when this happens. OR, you force default values down your
> object's throats. This is bad when the object you're using is volatile, and
> writes to a database or something.
>
> The complain is that implicitly allowing null returns means you have to
> check for null even if you're expecting an object. But *you have to do this
> anyway* if you're not hinting.
>
> +1 for return type hinting
> -1 for explicitly specifying null
> -1 for specifying multiple return types
>
>
> On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote:
>
> > Hi!
> >
> >> There will also be advantages for HipHop which can afford to spend the
> time to
> >> do static analysis of code -- I know that HipHop is not your baby
> >> but you now need to recognise that there is more than one PHP
> implementation
> >> and features that may not had much advantage with Zend may be useful
> elsewhere.
> >
> > If you want a statically typed language, there are tons of these on the
> market. However, unless you change PHP into another - statically typed -
> language, I do not see how it really helps.
> > What you talking about here is creating a dialect of PHP targeted for
> statically-compiled environment. I personally see it a bit pointless, since
> there are already many perfectly good static languages on the market, with
> excellent compilers and environments - so why not use any of these? But that
> shouldn't deter you - my personal opinion is just that, if you want to
> create your own static PHP, go ahead. But I do not believe doing it in
> little tweaks would work - if you want reliable typing, you need it
> everywhere.
> >
> > However, I seriously doubt PHP as a whole would benefit from it. Most
> uses of PHP are very dynamic and would not yield serious benefits from
> introducing static typing constructs beyond very specific cases in very
> specific environments. Changing the whole language to benefit these narrow
> scenarios does not seem beneficial to me.
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > 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] Return type-hint
Right, that's what null means. The difference in php is only in implementation
-- you actually just made my point :)
The only reason to have explicit null hints is if you get hung up on the whole
issue of how php actually implements NULL. The concept is "non value", distinct
from "empty". The implementation in php is slightly difference, since you're
not actually working with, say, a null pointer.
On Apr 28, 2011, at 1:05 PM, Martin Scotta wrote:
>
> Martin Scotta
>
>
> On Thu, Apr 28, 2011 at 2:51 PM, Matt Wilson wrote:
> Here's my issue:
>
> We're borrowing a feature from strongly typed languages and forcing it on a
> loosely typed language. I'm fine with this, if we're true to the concept.
>
> In a regular language, if you type something to return an object of type Foo,
> you might still get back null, and appropriately need to check for this. NULL
> is a perfectly valid state for an object.
>
> Probably core folks may know how this works better than me but I think that
> null is not an object, scalar or anything at all. It just means the absence
> of value.
>
> That's why I always thought that NULL meant "no value".
>
> function foo(Foo $f1, Foo $f2=null) {
>// $f1 can't be null
>// $f2 can be null
> }
>
>
> The objection I'm hearing to this is that because in PHP, null is a value and
> not a state, and since variables don't have types (values do), null should be
> an explicitly specified hint.
>
> To me, this is a nuclear bomb waiting to go off. If we allow the syntax
> described earlier (Foo | Bar | Null) we're violating the concept entirely,
> and there's no point in even having the feature. If a developer can type hint
> a function in such a way that you don't actually know what you're getting
> besides a subset of types, this has the exact opposite effect that return
> hinting is supposed to have. Now, I have to check for what type the value
> returned is, on top of null. Why even use return hinting?
>
> The other suggestion I've heard is to only allow for Object || Null, but this
> too seems ridiculous. The idea would be that if you're in a situation where
> you can't feasibly return the specified object, you should throw an
> exception. So now your code is going to be riddled with things like
> ObjectIsNullException, or generic handlers that don't know what to do besides
> go "OOPS!" when this happens. OR, you force default values down your object's
> throats. This is bad when the object you're using is volatile, and writes to
> a database or something.
>
> The complain is that implicitly allowing null returns means you have to check
> for null even if you're expecting an object. But *you have to do this anyway*
> if you're not hinting.
>
> +1 for return type hinting
> -1 for explicitly specifying null
> -1 for specifying multiple return types
>
>
> On Apr 28, 2011, at 12:36 PM, Stas Malyshev wrote:
>
> > Hi!
> >
> >> There will also be advantages for HipHop which can afford to spend the
> >> time to
> >> do static analysis of code -- I know that HipHop is not your baby
> >> but you now need to recognise that there is more than one PHP
> >> implementation
> >> and features that may not had much advantage with Zend may be useful
> >> elsewhere.
> >
> > If you want a statically typed language, there are tons of these on the
> > market. However, unless you change PHP into another - statically typed -
> > language, I do not see how it really helps.
> > What you talking about here is creating a dialect of PHP targeted for
> > statically-compiled environment. I personally see it a bit pointless, since
> > there are already many perfectly good static languages on the market, with
> > excellent compilers and environments - so why not use any of these? But
> > that shouldn't deter you - my personal opinion is just that, if you want to
> > create your own static PHP, go ahead. But I do not believe doing it in
> > little tweaks would work - if you want reliable typing, you need it
> > everywhere.
> >
> > However, I seriously doubt PHP as a whole would benefit from it. Most uses
> > of PHP are very dynamic and would not yield serious benefits from
> > introducing static typing constructs beyond very specific cases in very
> > specific environments. Changing the whole language to benefit these narrow
> > scenarios does not seem beneficial to me.
> > --
> > Stanislav Malyshev, Software Architect
> > SugarCRM: http://www.sugarcrm.com/
> > (408)454-6900 ext. 227
> >
> > --
> > 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] Return type-hint
On Thu, Apr 28, 2011 at 10:45:34AM -0700, Stas Malyshev wrote: > Hi! > > >I see many advantages of the introduction of return type hinting. > >- you can guarantee that your methods returns only what is explicitly > >stated (or else it blows up, the same as for arguments) > > You can't, because function resolution happens in runtime, so the only > point you know what the function called "foo" returns is the moment > where you're already calling it, not a moment before. The Zend engine does function resolution at run time - others (eg HipHop) can afford to do it at compile time and so will know at compile time. I will accept that sometimes it must always be done run time, eg: $funcName($arg) but that still allows most calls at compile time. Anyway - the check for return type would be done in the called function, not the calling function. > >- I think maybe the language itself could use that information, for > >performance, etc. improvements (we know that the return value will be > > That would need static compile-time binding of functions, which implies > static binding of includes, etc. - basically, compiling PHP code as a > whole in one monolitic application. Which might be acceptable for some applications. For those where it is not then this feature may not be useful. This is an *optional* declaration, not mandatory - so if it does not suit your purpose -- don't use it. -- Alain Williams Linux/GNU Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php #include -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hi! it's the same as for the current argument type hinting. you can access that information via Reflection http://hu2.php.net/manual/en/reflectionparameter.getclass.php Really? That's how you write your code - do a reflection check before every call? Nobody does that. why did we added ppp if people can define in the documentation(or in the method name :/) that which method is public and which isn't Well, this is a good argument, PPP case seems close. Still, PPP is not really as dynamic as variable types are - PPP picture is much simpler and it also serves the call target, not the caller - i.e., the caller does not rely on pretty much anything in PPP, while the target relies on its protected functions not being called by strangers. So my main objection is that return typing doesn't actually serve the caller. Also, the fact that for PHP is extremely common to return null/false from methods on error makes a big hole in this concept even if we accepted the return typing as a counterpart to existing argument typing. E.g., seeing something like: function (Foo|Bar|false|null) ugly() makes me fill dizzy. This doesn't look like something we'd want. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, 2011-04-28 at 20:04 +0200, Ferenc Kovacs wrote: > > Why I need being "saved" from documenting my code properly? Anyway, the > > function code defines the behavior, declaration of return type just ensures > > function would fail in runtime if your code tries to return unexpected data > > - but how is it helpful? The client of this function doesn't even know that > > before actually calling it! > > > why did we added ppp if people can define in the documentation(or in the > method name :/) that which method is public and which isn't with ppp i prevent the client code from doing something the function/class author didn't expect. With this return hint the function auther can force a runtime error when doing something wrong himself. (which he has to check one way or the other using tests etc.) johannes -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Martin Scotta
2011/4/28 Johannes Schlüter
> On Thu, 2011-04-28 at 20:04 +0200, Ferenc Kovacs wrote:
> > > Why I need being "saved" from documenting my code properly? Anyway, the
> > > function code defines the behavior, declaration of return type just
> ensures
> > > function would fail in runtime if your code tries to return unexpected
> data
> > > - but how is it helpful? The client of this function doesn't even know
> that
> > > before actually calling it!
> >
> >
> > why did we added ppp if people can define in the documentation(or in the
> > method name :/) that which method is public and which isn't
>
> with ppp i prevent the client code from doing something the
> function/class author didn't expect. With this return hint the function
> auther can force a runtime error when doing something wrong himself.
> (which he has to check one way or the other using tests etc.)
>
>
Return types are meant to ensure that you get what you asked for. This is
really useful when you need to delegate to some component, specially if it's
not of your own, although there are ways to avoid that patterns.
IMHO I would not trust on any return value, as PHP did not ensure anything
about them.
Even more, I do not write code that depend on return values, I prefer to
use input/output parameters,
This is the safer way I've found to achieve the same behavior
function no_return(ReturnStatus $returnStatus) {
doSomething();
if ( itWasOk() )
{
$returnStatus->setReturnValue( new Foo ); // return type hint
$returnStatus->success(); // return status
}
elseif ( isWasCritical() )
{
$returnStatus->setException( new RuntimeException );
$returnStatus->exception(); // return status
}
else
{
$returnStatus->fail(); // return status
}
}
Of course I don't write all functions like this.
This is pattern I use when I need to ensure that the type returned is valid.
johannes
>
>
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Re: [PHP-DEV] [RFC] Return type-hint
On Thu, Apr 28, 2011 at 8:49 PM, Stas Malyshev wrote: > Hi! > > > it's the same as for the current argument type hinting. >> you can access that information via Reflection >> http://hu2.php.net/manual/en/reflectionparameter.getclass.php >> > > Really? That's how you write your code - do a reflection check before every > call? Nobody does that. > > I didn't said that, probably I shouldn't have mention that, we are both aware of the capabilities of Reflection imo. but it's still true, that it would behave the same way as it does now for the argument type hinting. you didn't reply on that, so I think we agree on that. > > why did we added ppp if people can define in the documentation(or in the >> method name :/) that which method is public and which isn't >> > > Well, this is a good argument, PPP case seems close. Still, PPP is not > really as dynamic as variable types are - PPP picture is much simpler and it > also serves the call target, not the caller - i.e., the caller does not rely > on pretty much anything in PPP, while the target relies on its protected > functions not being called by strangers. > So my main objection is that return typing doesn't actually serve the > caller. > true, and Johannes brought this up also, but I didn't wanted to compare the ppp to return type hinting. I'm just saying that you argument "Why I need being "saved" from documenting my code properly?" isn't apply here. Because by this logic we could remove a lot of things, things which allows the developers to express their code more explicitly. "Anyway, the function code defines the behavior, declaration of return type just ensures function would fail in runtime if your code tries to return unexpected data - but how is it helpful?" as I mentioned I can imagine cases when we can spot errors before actually executing the code, but I don't know enough about the internals to tell that this could be viable or not. > Also, the fact that for PHP is extremely common to return null/false from > methods on error makes a big hole in this concept even if we accepted the > return typing as a counterpart to existing argument typing. E.g., seeing > something like: > function (Foo|Bar|false|null) ugly() > makes me fill dizzy. This doesn't look like something we'd want. > > yeah, but usually you return null/false in case of error when you write procedural code. but since we wouldn't support the return typehint for scalars, maybe we could assume that the only sane people who would use this feature would also do the error handling will through Exceptions (@throws :P). Tyrael
Re: [PHP-DEV] [RFC] Return type-hint
2011/4/28 Martin Scotta :
* snip *
> IMHO I would not trust on any return value, as PHP did not ensure anything
> about them.
> Even more, I do not write code that depend on return values, I prefer to
> use input/output parameters,
I cannot help but wonder why PHP is your language of choice. I mean no
disrespect, but PHP does not have strict typing (for a reason) and
forcing it upon PHP seems strange to me. Seeing as a) you'll either
have to implement the return type hinting yourself in which case you'd
know anyway what the return value is or b) you'd have to have others
implement it in their libraries in which case you'd have to wait years
for any noticeable effect, the feature seems useful only in edge cases
(such as Hiphop, which I think one can question the mainstream
usefulness of, currently).
Personally, I read code if I'm not sure what a given function/method
will return - or just test. I actually thought unit tests took care of
issues like this. I don't think having a list of possible return
values would make things simpler than the good old "try it and see" -
which is one of the greatest assets of PHP.
> This is the safer way I've found to achieve the same behavior
>
> function no_return(ReturnStatus $returnStatus) {
> doSomething();
>
> if ( itWasOk() )
> {
> $returnStatus->setReturnValue( new Foo ); // return type hint
> $returnStatus->success(); // return status
> }
> elseif ( isWasCritical() )
> {
> $returnStatus->setException( new RuntimeException );
> $returnStatus->exception(); // return status
> }
> else
> {
> $returnStatus->fail(); // return status
> }
> }
>
> Of course I don't write all functions like this.
> This is pattern I use when I need to ensure that the type returned is valid.
I just return what I need to from the function/method or throw an
exception. Indicating that you want to throw an exception instead of
actually throwing one seems ... overly polite, at best. As far as I
can tell, you'd have to check the ReturnStatus object anyway, so I
don't see how you're any safer (PHP has functions for checking null
values, false values, try/catch blocks and other things too). But
maybe we're dealing with very different development environments and I
just cannot see the usefulness of the suggested as it wouldn't make a
positive difference in mine.
Just a perspective from a typical webdev.
Regards
Peter
--
WWW: plphp.dk / plind.dk
LinkedIn: plind
BeWelcome/Couchsurfing: Fake51
Twitter: kafe15
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] SPLFileObject returns the content of a file after it was deleted
Hi, last week I wrote a bug report: http://bugs.php.net/bug.php?id=54570 Maybe someone can look into it, because no modifications were made since reporting. I am interested if it's a bug or If I should work around. Greetings Christian -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making SimpleXML more useful
> That patch is not a good idea. > > Assume you have this situation: > > > > > > > Adding a child "baz" to bar and have it default to no namespace Actually, my patch wouldn't change the default action of addChild(). It would still inherit the namespace qualification of the parent by default. > prefix would result in this: > > > > > > > > Now would be in the namespace "urn:lol". I don't see why this is a problem? I actually need to be able to add unqualified child elements. > Keep in mind that xmlns="" is, as per the XML spec, a perfectly valid > way to reset the namespace of an element. Right now, the behavior of addChild() is: * $namespace is unspecified --> inherit from parent * $namespace is specified --> use that as the namespace for the element (and this could be "") I need a third option, where I can add an element that is unqualified. There really are just two possible choices, either add a new "value" of $namespace (like (int) 0) that requests this behavior. Or, use some sort of magic namespace value (like "unqualified") to specify an unqualified element. Is there any opinion on which is better for addChild()? ... > SimpleXML is supposed to be simple (I find it more stupid than simple, but > that's my personal opinion). > I guess that's why it, by default, inherits the parent namespace The only way to make it less stupid, is to start fixing it. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Making SimpleXML more useful
While I think this would make SimpleXML more stupid, not less, as it seems braindead to me to allow users to create documents ambiguously and/or which essentially violate the XML namespace spec, I think the way to do this would be to define a magic constant and use that. E.g. const SIMPLEXML_DEFAULT_UNPREFIXED = 0 I used 'default unprefixed' to better describe what is going to happen in terms of namespaces (as within the context of a namespaced document is the only time this would be needed): the element is going to be created in the default namespace by virtue of being unprefixed. This highlights to the user the ambiguity involved (it is not necessarily known what the default namespace is at any point), as well as the 'priority' the XML generation will take at that point (of adding an unprefixed element). -1 for using "unqualified"; whatever is used should not be a possibly valid namspace name. Ben. On 29/04/11 7:48 AM, Tom Samplonius wrote: That patch is not a good idea. Assume you have this situation: Adding a child "baz" to bar and have it default to no namespace Actually, my patch wouldn't change the default action of addChild(). It would still inherit the namespace qualification of the parent by default. prefix would result in this: Now would be in the namespace "urn:lol". I don't see why this is a problem? I actually need to be able to add unqualified child elements. Keep in mind that xmlns="" is, as per the XML spec, a perfectly valid way to reset the namespace of an element. Right now, the behavior of addChild() is: * $namespace is unspecified --> inherit from parent * $namespace is specified --> use that as the namespace for the element (and this could be "") I need a third option, where I can add an element that is unqualified. There really are just two possible choices, either add a new "value" of $namespace (like (int) 0) that requests this behavior. Or, use some sort of magic namespace value (like "unqualified") to specify an unqualified element. Is there any opinion on which is better for addChild()? ... SimpleXML is supposed to be simple (I find it more stupid than simple, but that's my personal opinion). I guess that's why it, by default, inherits the parent namespace The only way to make it less stupid, is to start fixing it. Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hi! yeah, but usually you return null/false in case of error when you write procedural code. Nope. I use it all the time when writing OO code and when "nothing" or "no object" or "can't do this" is a valid answer for a function to return. but since we wouldn't support the return typehint for scalars, maybe we could assume that the only sane people who would use this feature would also do the error handling will through Exceptions (@throws :P). Exceptions are for _exceptional_ situations. If you query a DB for an object and there's no object like this, you don't want an exception if this situation is normal and handled in your code - you want a null or false or something like that. Exception is for situations that you code can not foresee or handle, they are not for regular data flow control. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] [RFC] Return type-hint
Hi! I will accept that sometimes it must always be done run time, eg: $funcName($arg) but that still allows most calls at compile time. This is not the issue. This is the issue: $foo->bar($arg). There's no way to resolve it in "compile time", whatever that means, without having a type on $foo. Anyway - the check for return type would be done in the called function, not the calling function. That's the point. You don't get any extra safety on the caller's side, because you don't actually know much about the called function. With checking arguments, it makes more sense as you are serving the called function - so you know the code that ensures types and the code that relies on this assurance is together and can rely on each other. There are other problems with it, but not this one at least. Here you have the assurance on one side and the code that relies on it on the other. Which might be acceptable for some applications. For those where it is not then this feature may not be useful. This is an *optional* declaration, not mandatory - so if it does not suit your purpose -- don't use it. You are talking about pretty big change in language nature - introducing strict typing. "It's just option, don't use it if you don't want" doesn't really sound good in this case. If it's in the language, it should make sense and sit well with the rest of the language. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
