Add hasser as property accessor

[adynemo]

Hi! 👋

This PR allows using hasser as property accessor. Hasser is another type of "getter" and acts like an isser.

Considering this following class:

class MyClass
{
  private bool $something;

  public function hasSomething(): bool
  {
    return $this->something;
  }
}

Now, we have to override the getter:

#[Type(class: MyClass::class)]
class MyClassType
{
    #[Field]
    public function getSomething(MyClass $myClass): bool
    {
        return $myClass->hasSomething();
    }
}

With that PR:

#[Type(class: MyClass::class)]
#[SourceField(name: 'something')]
class MyClassType
{
}

Just for information, I've made a search on the issue tracker and didn't find an issue about hassers and also run PHPStan and PHPUnit.

Thanks 🙂

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.81%. Comparing base (53f9d49) to head (e1a794b).
⚠️ Report is 125 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #766      +/-   ##
============================================
- Coverage     95.72%   94.81%   -0.92%     
- Complexity     1773     1846      +73     
============================================
  Files           154      175      +21     
  Lines          4586     4878     +292     
============================================
+ Hits           4390     4625     +235     
- Misses          196      253      +57     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[oojacoboo]

Why not just use this? I don't think it's practical that GraphQLite supports all these different auto method variations. If we support "hassers", we should support "issers" and whatever other boolean style people can think of, or prefer. This just isn't a good path to go down.

#[Type]
class MyClass
{
  private bool $something;

  #[Field(name: 'something')]
  public function hasSomething(): bool
  {
    return $this->something;
  }
}

[adynemo]

I understand your point. However, you're already supporting issers: https://github.com/thecodingmachine/graphqlite/blob/master/src/Utils/PropertyAccessor.php#L23-L34
That's why I've suggested hassers which are a pretty common getters type in several languages (i.e. Symfony serializer component supports them).

[oojacoboo]

That's a valid point. I don't think we should support "issers" either, frankly. It's probably too late to undo that decision without causing issues for people, though. It's just not a good design to have random methods strip off the first part of the method name for the GraphQL field. Personally, I've gotten hit with this on "issers", and have to go in and override the field name. It's also not smart enough to know the difference between public function issue() and public function isSue(), at least I don't think. And the same would be the case for public function hashKey() and public function hasHKey().

I'll leave this PR open to see if anyone else has any input. This would be a BC break also.

[oojacoboo]

@adynemo after some additional consideration on this, I think we can implement it, but with the addition of a new SchemaFactory config, like:

$factory = new SchemaFactory(...);
$factory->stripFieldPrefixes(['is', 'has', 'get', 'set']); // maybe a second param could be offered for ensuring the next character in the field name (that isn't stripped) is always lowercase, defaulting to true.

You'll need to rebase this PR branch and we'll need sufficient test coverage for this. As for the default, I guess we should keep it how it is now, to avoid BC breaks. If you have any feedback on that, happy to discuss.