class attribute :lexical_new

[leonerd]

First off: I don't like the name but I spent ages thinking on this and didn't come up with anything better, so... Suggestions welcome there ;)

Object::Pad has a class attribute called :lexical_new which has an effect on how the constructor method for a class is created. I'd like to suggest the same thing for core perl's class feature.

Every class gets a constructor method automatically created, which takes parameters and does all the work of assigning them into fields, creating the actual object instance, running the ADJUST blocks, and so on. Normally, without the attribute applied to the class, this method is then installed in the package for that class as a symbolically-named method called "new", meaning that any other code can invoke it by its publicly-visible name.

But sometimes you don't want that to be publicly visible. A publicly-visible constructor means that any other code is always able to create new instances of your class. There could be reasons you don't want that to happen.

For this reason, the :lexical_new attribute changes the generated constructor method so that it isn't installed as publicly-visible symbolic name in the class package, but instead is installed lexically within the block scope of the class as the "&new" lexical. This makes it visible to other code that the class package has chosen to provide, but invisible to outside callers. This makes it possible to provide other shapes of object construction; for example singleton or factory patterns. Code inside the class can provide class methods that make decisions about what constructor to invoke and how, or whether even to at all. The class can then be relatively confident that no outside code can bypass those wrappers, because the Class->new method is not visible.

class AUniqueInstance :lexical_new {
   my $instance;

   # It's the Singleton pattern
   sub instance ( $ ) {
      return $instance //= __PACKAGE__->&new;
   }
}

ok( AUniqueInstance->instance == AUniqueInstance->instance, "It's a singleton" );

AUniqueInstance->new;  # throws an exception

In fact this also makes it possible to provide constructors which take different shapes of arguments, by manually writing a new method that dispatches to the lexical one by reshaping its arguments. It can be especially handy for making object classes that only have one obvious construction parameter, allowing callers to pass it in positional rather than named style.

class Path :lexical_new {
   field $filename :param :reader;
   method new :common ($filename) {
      return $class->&new( filename => $filename );
   }
}

my $null = Path->new( "/dev/null" );

Though I should probably point out it's not always ideal to do that kind of thing, as it can make subclasses more difficult to reason about. But it's certainly possible. :)

[esabol]

Works for me. Being able to support the singleton pattern use-case and a single positional constructor parameter are useful and important features.

[trwyant]

I realize I'm out of my depth here, but ...

Under your proposal, could new() be re-implemented as (say) a factory, returning an object which is a subclass of the implementing class? That is to say, would there be an implementation for AUniqueInstance->new() in your singleton example? If so, what happens in subclasses?

One of the things I love about Perl 5's original ur-object system versus more traditional object systems such as (say) Java's is that new() is just another method. If I want an object of a given class, I simply call Class->new(), which returns whatever it sees fit. The fact that I need to get the object from a factory is encapsulated, reducing the cognitive load on the user of the object.

In more traditional object systems the user of a class must know whether to call a factory, or just instantiate the object directly. If a factory is needed, the user needs to figure out what it is called. At the very least this seems to me to violate the principal of Laziness, which I would like to see preserved in any core Perl object system.

[leonerd]

Under your proposal, could new() be re-implemented as (say) a factory, returning an object which is a subclass of the implementing class? That is to say, would there be an implementation for AUniqueInstance->new() in your singleton example? If so, what happens in subclasses?

Yes that's verymuch a thing that I already do with Object::Pad, and I'd like to continue doing with core perl too. For example, I have a class that represents a data protocol, and actually internally has two subclasses for transport over serial port vs over UDP. The constructor for this class is actually a factory that considers what kind of arguments were passed to it, and dispatches to one or other subclass because of that. I was going to mention that case more in a different upcoming idea post in fact. But yes it's very relevant here too.