But "variable" typehints
don't serve any such purpose. Actually, one could even say that they
don't serve *any* purpose, short of providing the IDE with type
information, because your code would work just as well even without
the type check. If the type were wrong, it would just throw a fatal
erro
Stas already pointed out that parameter typehints allow you to define
the interface for your method. Return typehints would server a similar
purpose and as such I'd consider them useful. But "variable" typehints
don't serve any such purpose.
I gave an example validating an array of Foo instances
Hi!
All right, your method accepts an array of objects, instances of Foo. How
do
you enforce this contract?
You are trying to re-invent generics/parametrized types and bolt it onto
PHP. I still don't think it is a good idea - PHP is not a statically
typed language. Just check you array elemen
Hi!
Let me ask you - do you think the existing PHP typehints are pointless
too?
Do you feel they don't give you enough flexibility? Do you feel they
reinvented a language construct for the purpose of saving the typing of
one
if clause (per argument) (per method) (per class)?
They are not po
On Wed, Aug 15, 2012 at 10:06 AM, Stan Vass wrote:
I'd like to also ask people to read what the intended effect of the
proposal
is instead of going into abstract discussions about how casting one class
to
another doesn't make sense (this is not what's being proposed).
I thi
And assignment is a kinda common operation. So I hope you can see what's
wrong with it now.
No I do not. Not every imaginable use case should have dedicated
language construct for it - sometimes it is OK to type 2 lines of code.
Sometimes even 3. This case is well served by existing language syn
What's wrong with instanceof? You can then throw fatal error if you
want, it's just two lines:
if(!($foo instanceof Bar)) {
trigger_error(E_USER_ERROR, "Wrong foo!");
}
That's 3 lines on top of the line where you assign the value, and you forgot
the 4th line for the IDE:
-
/* @var $foo
I'd like to also ask people to read what the intended effect of the proposal
is instead of going into abstract discussions about how casting one class to
another doesn't make sense (this is not what's being proposed).
Just like PHP typehints look like static typing but *aren't*, the same way
t
Hi!
I agree with you. The one case where this syntax may be very useful is if
we want to implement class casting. So introduce a pair of magic methods
I do not think we want to implement class casting. I'm not sure how
class casting even makes sense - if the object is of one class, how can
you
Proposed syntax:
-
$x = (InterfaceName) $container->service;
I'm against this. Let's be honest, how different is this that an
optionally static type?
InterfaceName $x = $container->service;
To be clear, I WANT optionally static typing. For the most part,
type-hinting
Would this work with methods which take arguments by reference or return by
reference?
Stan
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
I've felt the need for this for some time.
Proposed syntax:
-
$x = (InterfaceName) $container->service;
Proposed behavior:
---
Checks if the instance if an instance of the given class/interfaces. If yes,
does nothing, if not, issues a fatal error
You are either purposefully exaggerating or not doing it right.
if(fileop1() && fileop2() && fileop3()) {
// do valid stuff
} else {
// do error stuff
}
It's not that hard.
I guess it was my mistake that I simplified my actual code for simplicity's
sake. Please show me how would my actual cod
The overall mood seems to be that since PHP has an error handler, everyone is
free to handle errors any way they want.
Everyone is surprisingly ignoring the two giant holes in that theory:
1) PHP Errors come with a severity code and a string message. You want to
handle specific errors in a spec
Hi!
Because checking that the returned variable is `!== FALSE` is *way*
better than throwing an exception, right?
Yes, it is. You can control it, unlike the exception which you can not,
unless, again, you wrap everything into try/catch on every kind of
exception possible.
Have you stopped fo
if we turn E_STRICT to behave exactly as E_ERROR there is no point keeping
the E_STRICT level.
personally I disagree with turning something which was a pedantic notice in
one version into an unsupported feature which fatals out if you try to use it
in the next.
maybe E_STRICT->E_DEPRECAT
On Sat, Aug 4, 2012 at 1:16 AM, Stan Vass wrote:
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or what
the error severity is supposed to represent in general, because I&#
When I said I'd like to see E_STRICT be fatal/exceptions it wasn't a typo.
My choice isn't based as much on what the current error severity is, or what
the error severity is supposed to represent in general, because I've found
in PHP often the error severity has no connection with the error that
Which brings up the issues that I mentioned before.
Getting the return of an erroring function isn't such a big issue, but
turning everything into exceptions would prevent getting any return value from
any function/operation which triggers anything,
Maybe you want to keep your cake and eat
a php function/operation can raise more than one warning, how would you
handle that?
with exceptions you would only get the first one.
another issue is that with the current error handling model a call can
trigger a non-fatal error and still return some data.
with exeptions you can't do
Hi all,
Can anyone explain to me the reason that when a function or class is
disabled via the ini setting, an attempt to access the disabled item
generates a non-fatal error?
I'm looking at a segfault in the SPL caused by the blind creation of a
class, which seems to only fail when the class is
I'd like to apologize for my language. My goal isn't to insult anybody,
especially PHP contributors of major features like traits.
I hope we can talk strictly implementation issues, I think I have a good
idea how we can move this forward, I'll email you a list of behavior changes
that I think
Because it is not a matter of horizontal reuse.
Why don't you get a warning when you override an inherited method?
Because that is precisely the way things are supposed to work.
The body of a class is not a trait. These methods are not 'equals'.
I still think that design decision is a sensible on
From that follows that traits override the super class's methods.
And, conflict resolution is only done between traits, not between a class
and its traits.
The class body is a definite thing. Why would you purposefully add
something to a class body that conflicts with a trait?
The class needs to
Could you please point me *exactly* to the paragraph where we have
something written about static properties? I do not see that I wrote
anything special about static properties in the RFC. And I do not find it
in the docs either. static properties should work like normal properties.
I'd like t
The methods in the class have *always* higher precedence.
This is the same 'overriding' behavior used for inheritance.
From my personal perspective, changing this would lead to a major
inconsistency with how subclassing works.
Hi, I've subsequently read your RFC carefully and saw some of those
I'd like to point out some puzzling behaviors in Traits as they exist in the
production releases of PHP 5.4.
1. Name collisions between a trait method and a class method using the trait go
unreported, the class silently
It changes the semantics. If the variable is set to a falsey value and ?:
uses an implicit isset, the value of the expression will be the falsey
value.
$config['width'] = ''
$width = $config['width'] ?: 300
# $width == ''
If !empty were used instead of isset, you could preserve semantic
But OOP-like syntax on non-object data is still weird. The question about
data manipulation behavior (is it a pointer like other objects or is it a
scalar like existing array?) is a tough one.
For the user's point of view there is no difference between the passing
semantics of numbers/string pr
Chaos will surely be, if we break PHP5 code. It should work without
modification. wrote:
People are forgetting why we have version numbers.
Yes, it's very spectacular to have all the new stuff in a major release, but
that's not what major versions are for.
Major versions are for BC breaks. An
I do like the idea of pseudo-objects with methods as a way to create
much cleaner APIs for strings and arrays, but the legacy APIs need to
stick around.
You don't need to break BC to remove legacy APIs in PHP6.
#1. Introduce the new APIs in 5.x and gradually mark the old ones as
deprecated, b
m JS, that's good
(and I support it) but it needs to be nudged more towards PHP's PoV.
Re. number literals, (3).toPrecision(2) works in JS, I guess they wanted to
avoid some ambiguity in the parser, ex. 3.0.toPrecision(2).
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ke each other more useful, than
independently.
Let me know what you think.
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
m.
In terms of formatting of floats for humans, we still have printf() and
number_format(), which allow control independent of the ini setting (which
people use when they need that explicit control).
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
2624'
In the first example, the E notation, the API sends this to the database:
112589990684000, and was supposed to be 1125899906842624.
It's off by -2624.
The immediate fix for this is to keep *both* precisions to 17, and in the
long term, they should switch to serialize.precision and no
C rely on initialized class A, or
on some other initialization routine called in userland, which has not been
executed yet, producing "sometimes broken" code that's hard to debug.
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
ne on LLVM for
this, but I never heard about it since. And only then, esoteric things like
running on the GPU can be realistically pondered.
So, long way ahead...
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
== 15 // true
010 == 8 // true
'010' == 8 // false
It should be a important consideration that numeric string parsing isn't
affected by this patch, and things will be fine.
In fact it should be a separate discussion whether hex should work in
strings at all. It's very coun
fter repeatedly causing support issues.
T_DOUBLE_COLON already exists as a constant in userland, so the jump to it
won't be an epic change. Let's do it as a proof that we're not a nerd
gridlock bound to argue forever about even the most minor and obviously
positive changes
resolve that.
If it's not made valid, it'll be counter-intuitive as it looks exactly like
a constant passed as an argument.
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
provide concrete links to specific objections, instead of sending people to
hunt for the decisions manually.
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
loat 0, string '', empty array()
property_exists() more closely relates to "array_key_exists() for objects"
in that regard.
Stan Vass
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
his function required the existing behavior (i.e. can you
safely call property $x from the current scope with no warning?), and that
*ignored* when the behavior was changed. We already have Reflection classes for
inquiring protected/private properties of a class from any scope.
So, what happened here?
Stan Vass
43 matches
Mail list logo
