Hello kcott,

The former says it (i.e. the "XYZ") must be an object or class;

No, it says an object, or a class name. One might expect that the Perl interpreter would check that the name (i.e., string) supplied refers to an actual class/package, and in the normal case that is what happens, during method lookup. For example, Dog->bark() would be interpreted as a call to the bark method in the Dog class, so if there is no package Dog visible the lookup will result in a runtime error. (Likewise, if there is such a package but it doesn’t contain a bark method.)

But in the case in question — "XYZ"->$x("fred") — there is no lookup because the method to be invoked is fully specified by the coderef $x. And since there is no need for a method resolution, no check is done to verify that "XYZ" is a valid package/class name; instead, this string is simply passed through as the first argument to the method.

"I believe this parse option is needed to allow constructors to be called correctly."

I don't understand what you're referring to here. Could you expand upon this point. Thanks.

Nothing very profound. :-(  I was thinking of constructors, but I really should have said class methods generally (as opposed to object methods). Since in Perl a class/package is identified only by name, class methods are possible only if the parser recognises a form of method invocation in which the invoker is a class (package) name, i.e., a string. A constructor is just a special case of a class method.

Hence the "XYZ"->$x("fred") construct needs to be syntactically valid Perl. Whether "XYZ" is verified (necessarily at runtime) as a valid package name is an implementation detail. Choosing to validate class names only when necessary seems like a reasonable implementation choice for the parser.

Just my 2¢,