Bug: [Factories] when there are classes with the same short name, only the first class is loaded

[kenjis]

When there are classes with the same short name, and we try to load them with Factories by passing the full classname, only the first class is loaded.

There is no way to load the second class when specifying the full classname.

<?php

namespace App\Models;

use CodeIgniter\Model;

class Sample extends Model
{
 protected $table = 'samples';
 protected $allowedFields = [];
}

<?php

namespace App\Models\Dir;

use CodeIgniter\Model;

class Sample extends Model
{
 protected $table = 'dir_samples';
 protected $allowedFields = [];
}

<?php

namespace App\Controllers;

use App\Models\Dir\Sample as DirSample;
use App\Models\Sample;

class Home extends BaseController
{
 public function index()
 {
 $sample = model(Sample::class);
 $dirSample = model(DirSample::class);

 var_dump($sample === $dirSample);
 }
}

The result is true.

Related #7684

[kenjis]

Of course we can load the second class if we use the relative path:

$dirSample = model('Dir/Sample');

https://codeigniter4.github.io/CodeIgniter4/concepts/factories.html#loading-a-class-in-sub-directories

But it cannot specify the namespace.

[paulbalandan]

I don't understand the reasoning behind this basenaming logic. This very logic causes the bug in the Debug Toolbar where passing config(static::class) does not error since the class and its config share the same basename, Toolbar.

See 6f8f3a2

[kenjis]

@paulbalandan I think it is for implementing preferApp feature.
https://codeigniter4.github.io/CodeIgniter4/concepts/factories.html#preferapp-option

[paulbalandan]

In my opinion, if an FQCN is passed it should be just check only against class_exists and self::verifyInstanceOf and return. If a basename is passed (i.e. no namespace separators, like App), it should be checked if existing and satisfies the preferApp option when added the Config\ or App\Models\ namespace.

[kenjis]

@paulbalandan That is easy to understand, and it does not surprise devs.
I thought like that in the first time.

But the current behavior is intentional from the begininng. See #5356

If we change it, it will be a big change.

[kenjis]

@MGatner Why do you need preferApp ?
I think it is needed for Config, because devs need to use their own Config instead of a Config file in a Composer package.
But is it really needed for Models or other classes?

The current behavior is that if a developer happens to have a class in App/Models with the same short name, that class will be loaded instead of the class in a Composer package.
If there is App/Models/GroupModel, Shield's GroupModel will not be used, and Shield will not work correctly.

preferApp assumes that there are no classes with the same short name, which seems uncertain.
Also, to PHP devs, it is hard to assume that a different class will be loaded by specifying the FQCN.

We don't know which namespace Foo is loaded by model('Foo'), and we have no control over it if they are all in Composer packages.

[kenjis]

I found another bug or unexpected behavior with preferApp. #7699

[iRedds]

Who can explain in a nutshell why we need the model() function?
As I see it, this is an implementation of a singleton. So why not make a static method on the model that will return the same class instance?

UserModel::model() === UserModel::model()

Or a function that will store instances of objects.

singleton(Some::class) === singleton(Some::class)

[MGatner]

I think the solution here is to introduce a check for parent classes. So model('Shield\Models\UserModel') will only return App\Models\UserMdoel if it extends the Shield version. This way full class names can still be used and expected to return the call or one of its children. See my reference to how I implement a similar thing in Tatter\Handlers.

[MGatner]

Who can explain in a nutshell why we need the model() function?

The function is just a convenient wrapper for Factories. It functions similarly to a singleton but the power of it is to allow third-party modules to be extended natively. So if Acme\Foo has Acme\Foo\Models\WidgetModel and uses model(WidgetModel::class) to load it's own model, then devs can provide an alternate WidgetModel in App to be used in its place, without extending services or modifying the vendor package in any way.

[iRedds]

@MGatner I could be wrong, but it seems to me that most of those who encounter the problem voiced here are using the model() function as a class loader from CI 3 (i.e. $this->load->model()), and not the ability to replace models for third party modules.

What you're talking about, I think it should be solved like this.

// in module
model(\Acme\Some::class); // alias \Acme\Some::class for class \Acme\Some::class
// in app
model(\Acme\Some::class, \App\MyClass::class); // alias \Acme\Some::class for class \App\MyClass::class

Any subsequent call to model(\Acme\Some::class) after model(\Acme\Some::class, \App\MyClass::class) will return the \App\MyClass::class instance. That is, implement a service container.