December 20, 2019·4 min read·engineeringperlobjectsoperators

Perl adds an experimental class instance operator

Perl 5.31.7 introduces isa syntax for testing object membership. The operator handles non-objects safely and preserves custom isa methods.

Before asking an unknown value whether it belongs to a class, Perl code often checks whether the value is an object at all. Perl 5.31.7 adds an experimental infix isa operator for that combined question. The implementation commit describes its intended replacement for a blessed check followed by a method call. The December 20 release presents the operator in its development notes.

This is a small language addition with a specific purpose. It tests an object instance against a class or inherited class. A non-object produces false instead of requiring the caller to arrange the preliminary object check. That makes the expression useful at a boundary where a value may be absent, an ordinary scalar or an unblessed reference.

My strongest preference for Perl remains concise text work, so a new object operator is not a reason by itself to change how I choose the language. The addition is still useful because it gives a common question a defined treatment of invalid candidates. Short syntax is most persuasive when it also makes that boundary easier to understand.

The left operand must be an object

The operator documentation included in the release says isa returns true when its left argument is an instance of the named class or a class derived from it. It returns false when the value is undefined, is not a blessed object instance or does not derive from the requested class.

The right operand can be a bare class name or a scalar expression yielding a class name. That permits a fixed test as well as a name supplied by surrounding code. The implementation commit includes tests for both forms and for a variable containing the class name.

A minimal example follows those documented forms.

use feature 'isa';

my $value = bless {}, 'Example::Record';
my $matches = $value isa Example::Record;
my $absent = undef isa Example::Record;

The first test is true and the second false. The feature is experimental and emits a warning in the experimental::isa category. This example leaves that warning enabled so the code does not hide its status. Suppressing the warning is a separate choice from enabling the syntax.

The important improvement is the treatment of the left operand. A plain reference is not enough to qualify as an object. The commit tests an unblessed array reference and expects false. Undefined input likewise returns false. Those cases explain why the operator replaces more than just the spelling of an unconditional method invocation.

Existing object checks supply the context

The object manual at this release recommends a defined blessed check when the question is whether a value contains an object reference. It notes that ref reports all references, including ones that are not objects. A reference test alone therefore does not establish that the candidate is suitable for ordinary object method dispatch.

The implementation commit gives the older pattern as a blessed check joined to an isa method call. That arrangement asks two related questions. The first establishes that the value is an object. Its second question concerns the class relationship. The operator expresses that combined test with one infix construct.

This does not turn every reference into an instance of a class, and it does not treat a string naming a class as an object instance. Its documented domain is the instance on the left and the requested class on the right. Keeping those roles explicit avoids confusing an object-membership query with a general comparison between class names.

Perl's class model also remains relevant. The object manual describes parent classes through @ISA and says classes implicitly inherit from UNIVERSAL. The new operator uses the existing class relationship rather than introducing a separate class declaration system.

Custom isa methods still matter

The implementation commit explicitly says the operator respects isa method overrides. Its tests include a class whose isa method returns an answer based on the requested name's length. The test is deliberately unlike a straightforward inheritance lookup, so it demonstrates that the override is observable.

That detail limits how an application should interpret the result. Under ordinary behavior, the test corresponds to membership in the class or its inheritance hierarchy. A class that customizes isa can supply its own response. The operator's built-in syntax does not mean that it bypasses every customization and inspects only a raw inheritance list.

The object manual already permits classes to override methods inherited from UNIVERSAL and recommends retaining their documented semantics. The operator preserves that extension point. It therefore removes repetitive caller-side object checking while keeping the established method behavior for actual objects.

I find that compatibility choice sensible. A new syntax form should not silently invalidate a class's existing answer to the same membership question. The tradeoff is that readers must still understand the object model behind the expression. A keyword cannot make a customized class relationship more objective than the method supplying it.

The feature remains an experiment

The release documents a feature gate and a dedicated experimental warning. Its behavior may change, so acceptance by this interpreter does not establish a permanent language contract. The implementation commit supplies concrete tests for the initial behavior, including derived objects and non-object input.

There is a minor documentation inconsistency in the versioned operator manual, which says the feature is available from 5.31.6. The implementation commit is dated December 9, after that earlier release, and the 5.31.7 delta introduces it as new. The supported claim here is the operator's presence in the December release, backed by the implementation and its tests.

The same release also changes user-defined Unicode properties so they consistently override official properties of the same name. That is an independent compatibility decision about name resolution. For isa, the relevant boundary is simpler. The caller supplies a candidate value and a class name, non-objects produce false, and objects retain the membership behavior provided by their existing class machinery.