Skip to content

Take type names from phunkie instead of keeping a second table - #17

Merged
MarcelloDuarte merged 1 commit into
mainfrom
type-names-from-phunkie
Aug 3, 2026
Merged

Take type names from phunkie instead of keeping a second table#17
MarcelloDuarte merged 1 commit into
mainfrom
type-names-from-phunkie

Conversation

@MarcelloDuarte

Copy link
Copy Markdown
Contributor

Why

The REPL named types itself, and had drifted from the library whose values it prints. Both halves of the drift were visible in a single session:

phunkie > true
$var0: Bool = true              <- console's own getType()
phunkie > ImmList(true)
$var1: List<Boolean> = List(true)   <- phunkie's showType()

phunkie > 1.5
$var2: Float = 1.5
phunkie > ImmList(1.5)
$var3: List<Double> = List(1.5)

Same value, two names, in both directions.

What changed

getType() delegates scalar naming to phunkie's normaliseType(), so one place decides what a type is called. The hardcoded 'Int', 'Float', 'String', 'Bool' and 'Null' literals scattered through evaluateNode() now go through getType() for the same reason: each was a second opinion waiting to disagree.

It is fed by get_debug_type() rather than gettype(). That matters: gettype() returns "NULL" uppercase and spells floats "double", neither of which normaliseType is built around, whereas get_debug_type() returns the same lowercase names reflection uses, which is exactly what that table was written for.

Phunkie's names win, so the REPL now says Boolean rather than Bool57 assertions across 19 feature files updated to match.

Callable, Generator and object naming are unchanged; those are names the REPL genuinely owns, and getObjectType() already delegates to showType().

Behaviour changes

  • Bool becomes Boolean everywhere in REPL output.
  • Resources now report Resource rather than Unknown. The old default => 'Unknown' arm was only ever reachable for resources, and Resource is what phunkie calls them, so this closes a drift rather than opening one. No feature covered resources, so it was untested either way.

Requires phunkie 1.4

phunkie 1.4.0 standardises floats on Float. Together the two make the REPL agree with itself:

$var0: Boolean = true          $var2: List<Boolean> = List(true)
$var1: Float = 1.5             $var3: List<Float> = List(1.5)
$var4: ImmMap<String, Float> = Map("a" -> 1.5)

Verification

Behat and PHPUnit on 8.2, 8.3, 8.4 and 8.5 — 341, 384, 433 and 484 scenarios, 50 unit tests. PHPStan and PHP-CS-Fixer clean, composer validate --strict passes.

The REPL named types itself, and had drifted from the library it prints values
from. Both showed up in one session:

    phunkie > true
    $var0: Bool = true
    phunkie > ImmList(true)
    $var1: List<Boolean> = List(true)

getType() now delegates scalar naming to phunkie's normaliseType(), so there is
one place deciding what a type is called. The hardcoded 'Int', 'Float', 'String',
'Bool' and 'Null' literals scattered through evaluateNode go through getType()
for the same reason: each was a second opinion waiting to disagree.

get_debug_type() feeds it rather than gettype(), because gettype() returns
"NULL" uppercase and spells floats "double", neither of which normaliseType is
built around. get_debug_type() returns the same lowercase names reflection uses,
which is what that table was written for.

Phunkie's names win, so the REPL says Boolean rather than Bool. 57 assertions
across 19 feature files updated to match.

Resources now report Resource rather than Unknown. The old default arm was only
reachable for resources, and Resource is what phunkie calls them, so this closes
a drift rather than opening one.

Requires phunkie 1.4, which standardises floats on Float. Together the two make
the REPL agree with itself: Float and List<Float>, Boolean and List<Boolean>.

341, 384, 433 and 484 scenarios on 8.2 through 8.5, phpstan and cs-fixer clean.
@MarcelloDuarte
MarcelloDuarte merged commit db30f58 into main Aug 3, 2026
12 checks passed
@MarcelloDuarte
MarcelloDuarte deleted the type-names-from-phunkie branch August 3, 2026 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant