Why are all classes global?

[bscan]

Hi all, I'm excited for Corinna and appreciate the work everyone has done. I'm wondering about the global nature of classes, and the recommended style for file layouts.

In the spec, a class will generate a package of the same name without qualification. This means if a library uses an internal class User, then any code using that library will also have the User package.
Currently, Perl solves this issue primarily by convention: each package has its own file and the package name matches the file name.
These conventions are enforced via Perl::Critic (defaults Perl::Critic::Policy::Modules::ProhibitMultiplePackages and Perl::Critic::Policy::Modules::RequireFilenameMatchesPackage) and packages are coordinated globally via CPAN to ensure no two packages in any library have the same name.

Corinna appears to deviate from this norm in two ways: first, reducing boilerplate (e.g. sub new) encourages smaller and more frequent classes. Secondly, encouraging a block syntax class {} also appears to encourage people to have multiple classes per file. I would expect Corinna to generate far more classes than files, which could easily result in name collisions across modules and within applications if people are not careful.

Why not automatically qualify classes?

I'm sure this has been discussed, but I can't find the relevant discussion. The approach of prefixing the resulting package of a class with the package name of the file is an approach seen in Zydeco, and it uses factories to build the object instead of PackageName->new.
Prefixing it with something else entirely is a trick used in LeoNerd's Struct::Dumb, which generates a constructor named User() instead of a package named User (and places the actual package name elsewhere).

Style recommendation

Alternatively, is there a style recommendation for how to use Corinna classes to avoid name collisions?
Specifically, if I'm working on a package MegaCorp::Logistics and I need a class Ship, should I create a new file MegaCorp/Logistics/Ship.pm and name the class similar to a package?
With the code like:

package MegaCorp::Logistics::Ship;
use v5.38;

class MegaCorp::Logistics::Ship {
    use v5.38;
    ...
}

Or will it be possible to skip the redundant package name entirely and remove the block syntax from class?

Error Checking

Is it possible to add compile time errors for duplicate classes? Currently for normal packages and Object::Pad classes, duplicate declarations are assumed to be extensions of the same package. It would be nice to get an error like Sorry, the class Ship is already defined in MegaCorp/CruiseLines.pm as opposed to simply merging all the methods and fields.

Thanks!

[haarg]

class works basically the same as package. You would create a file MegaCorp/Logistics/Ship.pm with the content:

use v5.38;
class MegaCorp::Logistics::Ship {
    ...
}

Or:

use v5.38;
class MegaCorp::Logistics::Ship;
...

[bscan]

Thanks @haarg! Looking at the syntax discussion here https://github.com/Ovid/Cor/blob/822c19a30b1cc61502366c36f710af425ca0abd9/rfc/overview.md#261-syntax
it appears that block syntax will be required and plain class MegaCorp::Logistics::Ship; will be not be allowed. Otherwise, I would prefer the non-block form, which is the currently accepted convention where a package and a file are usually synonymous.

Object::Pad documentation mentions the non-block form and shows the following example:

use Object::Pad 0.16;
 
package My::Classname 1.23;
class My::Classname;

Although this is not ideal either since it requires duplicating My::Classname and still requires aligning the class name with the file name to prevent name collisions. Also, use Object::Pad 0.16; is run in package main, which I believe would cause the main namespace to be polluted (if Object::Pad exports anything).

What I would love to see is the ability to generate local classes (i.e. have class generate a package scoped constructor). Otherwise, we're still stuck in the same situation where every class should have its own file, except now everything in the file is indented one extra level.

[HaraldJoerg]

The duplication between package and class name is not required by Object::Pad, just the class declaration will do. The extra package line is not for the Perl runtime, but instead for tools which do not (yet) understand that a class declaration also provides a module and therefore fails to extract the version. See Perl-Toolchain-Gang/Module-Metadata#33 for details.

[leonerd]

In the feature-class branch, toplevel (called "unit") classes work absolutely fine:

class Some::Name::Here;
use whatever;
methods go here...

No need to indent the entire file one level for that pointless toplevel container block.

[Ovid]

I have to say that I feel uncomfortable with that primarily because I thought the design team agreed (albeit reluctantly) that maintaining the tight scope of the postfix block meant there would be less chance of new syntax leaking if someone later adds a package declaration to the same file. However, even if the postfix-block syntax of the spec is a bad idea (which it might be, culturally), I'd be concerned if the work delivered for the first pass of Corinna deviates too much from the spec.

That being said, this has been a strong enough point of contention that I see why people don't like it and I concede that it's probably not a showstopper.

And sorry for not responding sooner. I'm pretty busy with other things right now, so I'm slow.

[blues1875]

I'm a bit late to this party, but I believe it is still a valid question, and I don't really see an answer to the question of best practice for style. Did you come to any conclusion about that, @bscan? I agree with your comment that the block syntax lends itself to multiple small classes per file, but Perl Critic complains when you do that. I don't want to be a slave to Perl Critic, but I do try to follow it unless I have a good reason not to. But Corinna is still very new and a best style practice will surely emerge sooner or later. Chris Prather has a very good tutorial for a "roguelike" game, and that appears to use individual files for most classes, but he doesn't shy away from including multiple small subclasses within the same file.

[Grinnz]

Regardless of Corinna and block syntax (and perlcritic), the reason that one package per file is best practice is because this is the only way that "use" calls are guaranteed to be unsurprising to the user - to load and import from exactly one package with the same name that was asked for.

[bscan]

I agree with @Grinnz. Personally, I think Corinna examples should also emphasize this one class per file as best practice as well. Otherwise, we may end up in a situation where there are two modules on CPAN that can't both be used within the same project due to both defining Point or similar generic class.

Aside from shared modules like on CPAN, I would also find it confusing in any application. Imagine if you were working on Koha (library management software), and you couldn't build your a User class because Koha/Patron/Password.pm
also defined their own User class. In any application or shared CPAN module, we should use one class per file convention to prevent this confusion. I find this to be a limitation compared to the lexically scoped class definitions found in languages like Python and JavaScript. However, following the one-class-per-file prevents most issues.

I think Perl::Critic is probably correct to complain about multiple classes in one file (although probably requires Perl Navigator which normalizes class to package for PPI to understand).

[Ovid]

The annoyance here is that all namespaces in Perl are global. Modules sometimes jump through hoops to address this. There's been some discussion on P5P about this. I would love this:

namespace Las::Vegas {  # postfix block optional
    class Point { ... }
}

And so long as the top-level namespace is unique, I can have my own Point class without fear. Throwing private classes into the mix would help, too. However, we're not there yet, so one class per file is probably best practice for now.

[bscan]

@Ovid, agreed. Namespaces would be nice. Alternatively, the approach I really like is from Struct::Dumb which automatically prefixes the struct name with the package name

package Las::Vegas {
    struct Point => [qw( x y )];
    # Above code creates Las::Vegas::Point package, and a constructor named `Point`    
}

Prefixing a class with the outer package name appears to solve most of these issues. And then instead of useing the package, you would explicitly import the constructor. Namespacing for subroutine definitions works very well already. Most of the time, the only thing I want from a class is the constructor and then I'll access everything else through methods. And then be willing to fully path it when static methods are needed.

Regarding that P5P thread, I didn't see anyone mention Perl::Critic's Modules::RequireExplicitInclusion which is another method for solving the issue mentioned.