Hi,
I came up with a solution for #50224 (https://bugs.php.net/bug.php?id=50224)
on the PR https://github.com/php/php-src/pull/642
Has a lot discussion on the PR, but since July 31st there is no response.
The main open discussion is in which version to apply it.
Thanks,
Juan Basso
Sara Golemon wrote (on 17/09/2014):
My general feeling is to leave it alone. I agree that it's a misnomer, but as
has been mentioned, it's a well established misnomer. I don't see a big gain
from it apart from academic purity.
I guess in that way it's similar to "overloading", which has a r
Matthew Fonda wrote (on 17/09/2014):
Hi Andrea,
This is great -- thanks to you and Nikita for the work here.
Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b,
'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable,
and it avoids any possible confusion ab
Christian Stoller wrote (on 17/09/2014):
I'd say that it is absolutely legal to define a more specialized
type in a child or implementing class, or would this have any bad
side effects?
Here is a StackOverflow question discussing exactly this issue, which
includes why you can't do that with an
> -Ursprüngliche Nachricht-
> Von: Rowan Collins [mailto:rowan.coll...@gmail.com]
> Gesendet: Mittwoch, 17. September 2014 18:01
> An: internals@lists.php.net
> Betreff: Re: AW: [PHP-DEV] Renaming type-hints to something else?
>
> Robert Stoll wrote (on 16/09/2014):
> > I would argue "typ
Hi Andrea,
This is great -- thanks to you and Nikita for the work here.
Syntax wise, I would prefer a function-like syntax, e.g. coalesce($a, $b,
'c') or ifsetor() instead of $a ?? $b ?? 'c'. I find this more readable,
and it avoids any possible confusion about precedence within the
expressions.
Robert Stoll wrote (on 16/09/2014):
I would argue "type declaration" is wrong as well since it is not a type
declaration as it is known in other languages where the type declaration is
binding. IMO it is more a "type check". Consider the following
function foo(Bar $b){
$b = 1; //$b is not a B
From: Johannes Schlüter [mailto:johan...@schlueters.de]
> Thus having
>
> function bar(C $c) {
> $a = new A();
> $c->foo($a);
> }
>
> might work or might not work as $c might be an instance of D. Thus
> breaks the Liskov Substitution Principle
> http://en.wikipedia.org/wiki
On Wed, 2014-09-17 at 16:52 +0200, Christian Stoller wrote:
> Hello all,
>
> I hope the subject is not misleading. Please look at the following code:
>
> class A { }
>
> class B extends A { }
>
> interface C {
> function foo(A $a);
> }
Here you say "any A can be pa
On Wed, Sep 17, 2014 at 8:52 AM, Christian Stoller wrote:
> Hello all,
>
> I hope the subject is not misleading. Please look at the following code:
>
> class A { }
>
> class B extends A { }
>
> interface C {
> function foo(A $a);
> }
>
> class D implements C {
>
On 17 September 2014 15:52, Christian Stoller wrote:
> Hello all,
>
> I hope the subject is not misleading. Please look at the following code:
>
> class A { }
>
> class B extends A { }
>
> interface C {
> function foo(A $a);
> }
>
> class D implements C {
>
Hello all,
I hope the subject is not misleading. Please look at the following code:
http://3v4l.org/l2M0f).
I don't get the reason for that behavior (and I could not find any
documentation about that, at least not at
http://php.net/manual/en/language.oop5.typehinting.php).
I have already fo
On 17 Sep 2014, at 15:43, Levi Morrison wrote:
> Dropping the suffix:
> --
> class ReflectionType
>
> Methods:
> ReflectionFunction::hasReturnType
> ReflectionFunction::getReturnType
> ReflectionParameter::hasType
> ReflectionParameter::getType
This seems to be
> This also manifests itself to users because of reflection as well.
I think maybe writing out a few possible class/method names might be helpful:
Using Hint:
--
class ReflectionTypeHint
Methods:
ReflectionFunction::hasReturnTypeHint
ReflectionFunction::getReturnT
On Wed, 2014-09-17 at 16:03 +0200, Johannes Schlüter wrote:
>
> If this is changed is done I'd suggest escaping the regexp accordingly
> to be on the safe side.
ah, I see this is already done. Still see no big need to limit this to
ASCII (yes, I read the user's report)
johannes
--
PHP Intern
On Wed, 2014-09-17 at 21:51 +0800, Tjerk Meesters wrote:
> Hi,
>
> I’ve authored a fix for browscap:
> https://github.com/php/php-src/pull/827
>
> Bug report: https://bugs.php.net/bug.php?id=68021
>
> It replaces the current expression delimiters of \xA7 with a tilde (~)
> that’s ASCII compatibl
Hi,
I’ve authored a fix for browscap: https://github.com/php/php-src/pull/827
Bug report: https://bugs.php.net/bug.php?id=68021
It replaces the current expression delimiters of \xA7 with a tilde (~) that’s
ASCII compatible and therefore plays nice with UTF-8.
Seems like a no-brainer to apply t
2014-09-17 10:58 GMT+02:00 Sara Golemon :
>
>> On Sep 16, 2014, at 13:46, "Kingsquare.nl - Robin Speekenbrink"
>> wrote:
>>
>> As a userland point of view on this: will this have a shorthand? i.e.
>> what will happen if i leave out the second part?
>>
>> ie.
>> $var = $_GET['test'] ?? ;
>>
>> wou
Both decisions make sense. I'm indifferent which one to make.
Just not to keep the undocumented inconsistency :)
Thanks. Dmitry,
On Wed, Sep 17, 2014 at 3:00 PM, Derick Rethans wrote:
> On Thu, 11 Sep 2014, Dmitry Stogov wrote:
>
> > Please take a look and make your opinion.
> >
> > https://wik
On Thu, 11 Sep 2014, Dmitry Stogov wrote:
> Please take a look and make your opinion.
>
> https://wiki.php.net/rfc/fix_list_behavior_inconsistency
>
> This inconsistency might be interpreted like a bug, but fixing it might
> break existing PHP code (at least my attempt to fix it in documented wa
On 17/09/14 09:46, Sara Golemon wrote:
> As for Hint versus Declaration/Decl or Annotation or whatever... My second
> choice (since staying with hint is my first) is probably decl(aration).
> Despite my HHVM loyalties, I'm not fond of using "annotation" here anyway.
> There's a reasonable argu
> On Sep 16, 2014, at 13:46, "Kingsquare.nl - Robin Speekenbrink"
> wrote:
>
> As a userland point of view on this: will this have a shorthand? i.e.
> what will happen if i leave out the second part?
>
> ie.
> $var = $_GET['test'] ?? ;
>
> would that be the same as
> $var = @$_GET['test'];
>
> On Sep 16, 2014, at 8:11, Levi Morrison wrote:
> Can anyone come up with a better name than `hints`? Maybe `type
> declarations`? Or should we just stick with `hints`?
My general feeling is to leave it alone. I agree that it's a misnomer, but as
has been mentioned, it's a well established mi
>
>
> What do you guys think?
>
Has the ship not already sailed on this one? The php.net web site (
http://php.net/manual/en/language.oop5.typehinting.php), and userland
developers, have been calling them type hints for years now, I'd imagine
whatever new name comes up will largely be ignored outs
24 matches
Mail list logo