Hi!
Which a good compiler with time to burn (think HipHop not Zend) could do, eg:
1. I think you overestimating the capabilities of HipHop, but I can be
mistaken.
2. HipHop represents a minority of use cases for PHP, I do not think it
is practical for PHP to target only monolitic pre-compile
On Apr 29, 2011 4:47 PM, "Martin Scotta" wrote:
>
>
> Martin Scotta
>
>
> On Thu, Apr 28, 2011 at 5:15 PM, Peter Lind
wrote:
>>
>> 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
Martin Scotta
On Thu, Apr 28, 2011 at 5:15 PM, Peter Lind wrote:
> 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 inpu
>
>
> 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 - in
On Thu, Apr 28, 2011 at 10:05:01PM -0700, Stas Malyshev wrote:
> 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
On Fri, Apr 29, 2011 at 7:04 AM, Stas Malyshev wrote:
> 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 func
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
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 f
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 m
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 reflec
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 run
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
> > - b
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
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 fu
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
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 r
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 functio
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 n
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 fu
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 e
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
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 t
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
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
> t
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 fu
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
> }
>
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,
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
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
tha
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
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 pro
>
>
>
> 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
>
ma
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
>
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
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 unc
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
On Wed, Apr 27, 2011 at 11:29 AM, Pas wrote:
> On Wed, Apr 27, 2011 at 09:23, Ferenc Kovacs wrote:
> > On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena
> wrote:
> >
> >> Hi all,
> >> I've updated the patch and the RFC that proposes the return type-hint
> >> implementation (Engine + Reflection).
> >
There was no consensus on that, but as i remember the tendency was more to
the weak type hinting because of dynamic nature of PHP. You know - all the
http data comes as strings, most db data comes as strings and so on.
27.04.2011 11:30 пользователь "Pas" написал:
> On Wed, Apr 27, 2011 at 09:23, F
On Wed, Apr 27, 2011 at 09:23, Ferenc Kovacs wrote:
> On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena wrote:
>
>> Hi all,
>> I've updated the patch and the RFC that proposes the return type-hint
>> implementation (Engine + Reflection).
>> The proposed implementation is working just like the last cha
On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena wrote:
> Hi all,
> I've updated the patch and the RFC that proposes the return type-hint
> implementation (Engine + Reflection).
> The proposed implementation is working just like the last changes in the
> parameter type-hint (in trunk). i.e. working w
+1 for "one could use the full qualified name to refer to the class name".
Making the developer care about the case of characters in one special case -
that's the sort of changes that lead to chaos. Remember that type conversion
works in a case-insensitive manner and so does most of the language
c
On 29 July 2010 13:57, Felipe Pena wrote:
> My suggestion (I guess already told it in some mail...) is to
> identify the native php type just when it's lowercased (case-sensitive).
Alternatively, one could use the full qualified name to refer to the
class name, e.g.
function expectsScalar(string
Hi
2010/7/29 Ferenc Kovacs
> >> Hi, I would love this feature.
> >> But I have some concerns.
> >> AFAIK you can declare classes with the name int ,scalar, etc. so
> >> hinting anything else than class names can be ambiguous.
> >> Or we have to set these keywords as reserved, so nobody could dec
On Thu, Jul 29, 2010 at 9:47 AM, Adam Harvey wrote:
> On 29 July 2010 15:43, Ferenc Kovacs wrote:
>> ps: the spam filter rejected my previous email because of the
>> codesearch links...
>
> This happened to me repeatedly the other day, too, even with an e-mail
> that ultimately didn't feature any
>> Hi, I would love this feature.
>> But I have some concerns.
>> AFAIK you can declare classes with the name int ,scalar, etc. so
>> hinting anything else than class names can be ambiguous.
>> Or we have to set these keywords as reserved, so nobody could declare
>> classes with such names.
>
> Wer
On 29 July 2010 15:43, Ferenc Kovacs wrote:
> ps: the spam filter rejected my previous email because of the
> codesearch links...
This happened to me repeatedly the other day, too, even with an e-mail
that ultimately didn't feature any links at all. Can someone with
admin access see if the mail f
On Thu, Jul 29, 2010 at 09:43, Ferenc Kovacs wrote:
> On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena wrote:
>> Hi all,
>> I've updated the patch and the RFC that proposes the return type-hint
>> implementation (Engine + Reflection).
>> The proposed implementation is working just like the last chang
On Thu, Jul 29, 2010 at 3:49 AM, Felipe Pena wrote:
> Hi all,
> I've updated the patch and the RFC that proposes the return type-hint
> implementation (Engine + Reflection).
> The proposed implementation is working just like the last changes in the
> parameter type-hint (in trunk). i.e. working wi
I would like to see this in the next major/minor release, together with
the traits and the type-hint implementation. This would be a great language
improvement.
>From my end-developer standpoint a big +++
On Wed, 28 Jul 2010 22:49:03 -0300, Felipe Pena
wrote:
> Hi all,
> I've updated the patch
Hi all,
I've updated the patch and the RFC that proposes the return type-hint
implementation (Engine + Reflection).
The proposed implementation is working just like the last changes in the
parameter type-hint (in trunk). i.e. working with the "scalar" and "numeric"
pseudo-types.
http://wiki.php.ne
50 matches
Mail list logo
