search

perlang-org / perlang

The Perlang Programming Language
https://perlang.org
MIT License
16 stars 1 forks source link

Add `object` type #251

Closed perlun closed 1 month ago

perlun commented 2 years ago

Moved to GitLab

Please continue to the new version of this issue here: https://gitlab.perlang.org/perlang/perlang/-/issues/251. The GitHub page you are currently reading will not contain the latest information on this issue.

Sometimes, it's useful to be able to be able to reassign a variable which is a string with something else like an int. While this definitely has its drawbacks, not having such a concept at all in Perlang also has other drawbacks...

(I realized this while incorporating the and tests from lox; it makes use of the feature often present in dynamic languages where a variable can be freely reassigned something of a different type. This test is currently impossible to implement as-is in Perlang.)

perlun commented 2 years ago

This is surely useful, but it also requires some thought: for example, we don't support casting at the moment. A generic object type is more or less useful without support for at least casting from a more specific type (like string) to a more generic type (like object). Ideally, casting from object to more specific types (like string) as well, but let's be very aware that by enabling this, we open for up for all forms of dangerous run-time exceptions because the type casting cannot be satisfied. Do we really want this? Are we ready for it? :thinking:

Also, should we use a unified type system like C#? We currently execute in a .NET virtual machine (where this would be natural), but as I think I've mentioned elsewhere, I don't want to (at this point) rule out the possibility for other execution forms at a later point. Having that said, I do feel that a unified type system "feels more natural" to me as a developer than the approach taken by e.g. Java (where primitives are handled differently, and not yet usable with generics etc[^1]), so it's quite likely that we'll end up with that.

Deferring for "Later" for now.

[^1]: JEP 401 and 402 are two steps in this direction. This draft JEP then deals with the actual support for "primitive classes" in generics, but it is in an earier stage than JEP 401 and 402.