PHP compile time generics: yay or nay?

I thought Hack is dead or not intended for public use anymore.

But after some quick checking, I learned that Hack is still actively maintained, surprisingly.

Nailed it.

This is the core problem with PHP for me.I love PHP and use it every day. Part of that is the strength and versatility of the arrays implementation (i.e. hashmap). However, the problem is always the fact that an array cant be typed.

IF they could just introduce that, it would solve 80% of user-land issues over night.

We used to have a lot of classes like that, but for us PHPStan is sufficient and we effectively have generics now through static analysis warning us of improper usage of types in our CI and IDEs.

Is this not suitable for you?

Example, Java is using erased generics. Once the code is compiled, the generics information is no longer in the bytecode. List<String> becomes List<>. This is called type erasure.

C# is using reified generics where this information is preserved. List<String> is still List<String> after compilation

With reified generics, the code

  class Foo<X> {
    X x;
  }

  Foo<int> fooInt;
  fooInt.x = 5;
  Foo<float> fooFloat;
  fooFloat.x = 5.0;

compiles to:

  class Foo_int {
    int x;
  }

  class Foo_float {
    float x;
  }

  Foo_int fooInt;
  fooInt.x = 5;
  Foo_float fooFloat;
  fooFloat.x = 5.0;

On the other hand, erased generics compiles to this:

  class Foo {
    void* x;
  }

  Foo fooInt;
  fooInt.x = new int(5);
  Foo fooFloat;
  fooFloat.x = new float(5.0);

I'm not smarter than you but.

I believe the terms reified generics and erased generics is the type sweaty donkey ball terminology you get for professional CS academics.

Sticking my neck out further.

Reified generics means the type is available at run time. In C# you can write if(obj.GetType() == typeof(typename))

Erased generics the type information is not available at run time. That's the way Java does it and it kinda sucks.

The former merely exposes a `BlogPostRepository` class. The latter requires some mechanism for creating a generic object of concrete type, which is a lot bigger change to the implementation. Does each parametrized generic type have its own implementation? Or does each object have sufficient RTTI to dynamically dispatch? And what are the implications for module API data structures? Etc. In other words, this limitation avoids tremendously disruptive implementation impacts. Not pretty, but we're talking PHP here anyway. ;-)

Usually you are right. I assume the inability to sugar would be that "because PHP", the value/type of BlogPost can not be derived at compile-time?

Today, the vast majority of commercial PHP projects are developed enforcing the use of strong types by static analyzers like PHPStan in the CI pipeline, and having the strict_types declaration set.

As a community, we've seen enough untyped PHP spaghetti code in the early 2000s and never want to go back there.

Generics are not equivalent to loose types.

> they want to implement generics to have more loosely typed code

That's a weird way to think about generics. Any class using generics effectively functions as a version of the class where the types are explicitly written out in all places. Instead of writing out one version of the class for every generic type, you write it out once and say which version you want to use at instantiation. You lose no safety, it's purely cosmetic and quality of life.

Addition, as I missed the edit window.

I wish they would elaborate on what Really Really Hard(tm) means. From a high-level I believe everything they are concerned with has been researched as part of the work on contract by Robby Findler and collaborators. E.g. https://users.cs.northwestern.edu/~robby/pubs/papers/popl201...

PHP afair compiles the textual PHP into some intermediate which is then run. So there is a compilation stage.

As you say, generics really only apply to typed languages, and they help solve very legitimate annoyance in most of those languages -- you often have some library helper or algorithm that can apply to a wide range of things, but those things differ in some way that's irrelevant to the algorithm.

For example, a mergesort algorithm works on any kind of array, as long as you can compare the elements in the array to each other. There's no point in re-implementing the algorithm for each kind of array. Yet, without generics, you'd need to do just that. At the same time, the generated code for sorting each different kind of array might need to be a little different - comparing strings and floats isn't the same assembly, for instance. So the programming language and compiler work together: you specify the algorithm once in a certain way, and the compiler can generate the right version of algorithm for each way that you need to use it.

There are many, many good reasons why you might want to work in a typed language, even though specifying the types is a bit of extra book-keeping; generics are one way to keep the pointless work down. Of course, if you can get away with a python script, there's no need to bother with all this typing business just yet, either.

> "we want these elaborate type systems, but we also want typeless because that is far more convenient to use, so we invented generics, a method to untype your type system"

It's rather the exact opposite. Parametric types are a way to properly type "deeply" instead of just the topmost layer. Just like inference, type parameters don't remove types.

> isn't that just python, strongly typed but your functions don't have built in type checks.

That doesn't really make any sense? Static types mean you don't have runtime type checks, since the types are known statically.