I like how it's lowly becoming more and more a typed language.
Anyway, nice updates, but don't really see much changes overall

https://php.net/releases/8.0/...

Wow this is surprisingly good

Because strict typing is not a curse but a blessing.

Amen!

Let's hope to get variable types in the next version.

It's about time, honestly. 🤣

I will never understand the mentality that answers the question, "hey, how about we let the machine tell you when you're about to run into a predictable failure because of the intent your code conveys," with, "I'd prefer not to."

@SortOfTested Yeah, with modern type inference there really isn't any argument left for dynamic typing

Too late. Those who care moved on a long time ago, and those who don't aren't going to use it anyway.

@SortOfTested

if(gonna_fail())
don't()

@12bitfloat duck typing is still an argument though. But not for weak typing. Weak typing is a curse.

@iiii Nah, duck typing essentially *is* weak typing and both are horrible

Just because I have a method next() doesn't make me an iterator. The only entity that can judge whether I am is a human able to read and interpret the documentation which contains vital semantic information not expressible in code

@12bitfloat no, it's not. Having the same interface as some other type is not equal to be automatically converted to some other arbitrary type.

In the first case types are still honored, but you don't need a strict inheritance to be polymorphic, while in the second case it's a fucking random wild west.

@iiii
I think he's just discriminating between duck typing and structural typing. Duck typing checks occur at runtime, structural typing performs the same check at compile time.

@SortOfTested oh, fair enough. I am for static type checks.

@ SortOfTested also I did not know it was called a "structural type system"

@iiii @SortOfTested I don't like duck/structural typing whether it happens at compile time for this reason:

A method signature does not hold enough
semantic information to judge compatibility

Can next() return null? Can it return not-null after it returned null? Does it throw exceptions? When? Does it have any significant side effects?

These are things that you can't express in a signature yet are vital to robust code

@12bitfloat the same set of questions goes to overloaded methods of descendants. There's no difference.

@iiii Duck typing and weak typing are very similar though

Weak typing does implicit conversion while duck typing does implicit interface implementation (for lack of a better term). But in both cases your values are implicitely coerced to different semantics

@12bitfloat weak typing and duck typing aren't similar.

The only thing duck typing does is checking for an existence of an interface with a specific signature. You can do that with strong typing easily. It does not imply any implicit implementation. Interface either exists or not.

@iiii Weak typing: A string can magically act like a number

Duck typing: My object can magically act like an iterator

In what world are these not similar ideas?

@12bitfloat wrong.

Duck typing is: my object has an interface foo() therefore it could be used in a context requiring interface foo().

It does not "magically act as other object". It acts as an object with an interface foo(), which it is.

PS: also take note that interface also has to have the same signature and not only the same name to be considered the same interface.

@iiii My object -- which does not explicitely have the interface Iterator implemented -- magically implements that Interface because it has matching methods

It IS magic because it happens at a distance without your control. That's literally what that means

And this is exactly what I'm critiquing, and what I have explained twice now but what you have conveniently ignored both times

**A method signature does not hold enough semantic information to deduce compatibility**

@Z-GOD That's the downside of a badly designed language. When you actually try to fix it (like they do, let's be fair) you HAVE to break backwards compatibility in a major way

@12bitfloat being a descendant of an iterator class does not guarantee the interface was implemented correctly.

In either way it is a trust in interface being implemented and used correctly. If an idiot uses a system, there's no guarantees whatsoever. If you use incompatible "non-iterator" where iterator behavior is expected, it's not the system's problem, but yours.

@iiii Yes, but the problem I'm getting at is that in one case you are explicitely and positively asserting that your class follows the iterator interface semantics as required in the docs, where as in the other case it's just implicitely assumed that it'll be alright because the method signatures happen to match

@SortOfTested I’ve never heard a more spot on statement about the strange mentality of proponents of weakly typed systems :D

Very nice!