This repository has been archived on 2023-08-20. You can view files and clone it, but cannot push or open issues or pull requests.
symfony/src/Symfony
Fabien Potencier 20a9961711 merged branch jjbohn/feature/property-path-hasser (PR #3549)
Commits
-------

b6ac1aa [FORM] Give PropertyPath ability to read hassers

Discussion
----------

[Form] Give PropertyPath ability to read hassers

Bug fix: no
Feature addition: yes
Backwards compatibility break: no
Symfony2 tests pass: yes
Fixes the following tickets: -
Todo: -

Using a `hasser` instead of `isser` for Boolean values is pretty common. I've found myself using `issers` a handful of times just to make an interface play nice with the form component, but the code reads funny now. I don't think we should be accounting for every possible `getter` variation, but I think this one is common enough that it warrants a discussion.

---------------------------------------------------------------------------

by fabpot at 2012-03-11T08:25:31Z

I tend to agree with with. What do you think @bschussek?

---------------------------------------------------------------------------

by kriswallsmith at 2012-03-16T22:42:28Z

I'm not so sure. There are lots of reasons to write a *hasser* that accepts an argument (i.e. `User::hasRole($role)`). Doesn't seem as clean as *issers* and *getters*.

---------------------------------------------------------------------------

by vicb at 2012-03-16T22:49:14Z

> There are lots of reasons to write a hasser that accepts an argument

May be can check for 0 args as we are already using reflexion ?

---------------------------------------------------------------------------

by kriswallsmith at 2012-03-16T22:55:43Z

In that case we should check that there are either 0 arguments or only optional arguments and also consider adding the same logic to the other varieties.

---------------------------------------------------------------------------

by jjbohn at 2012-03-16T23:37:47Z

Passing arguments seems like a pretty big departure for PropertyPath. How would you annotate that? I'm not sure I see a common use case for needing arguments when mapping data to and from forms.

---------------------------------------------------------------------------

by stof at 2012-03-16T23:50:22Z

@jjbohn it is not about passing arguments but about using the hasser only if it does not have required arguments

---------------------------------------------------------------------------

by jjbohn at 2012-03-17T01:54:18Z

Ah. I see. I have a tendency to read @kriswallsmith comments wrong :D. I could see that but iirc, there's not any current check like this on the other accessors. Happy to add it though if there's a consensus.

---------------------------------------------------------------------------

by fabpot at 2012-03-17T11:24:34Z

What's the point is checking the hasser/getter/isser arguments. It's up to the developer to check if he can use them or not. Let's not complexify the code for this.

---------------------------------------------------------------------------

by kriswallsmith at 2012-03-17T15:37:39Z

My concern is that someone writes a hasser method on their model that is not intended for use with the form component but it's called anyway, leading to WTFs.

---------------------------------------------------------------------------

by stof at 2012-04-03T22:28:21Z

@fabpot what's your decision about this ?

@jjbohn you need to rebase your PR. It conflicts with master as tests have been moved

---------------------------------------------------------------------------

by bschussek at 2012-04-05T14:53:55Z

@kriswallsmith is right. The check for 1 === $method->getNumberOfRequiredParameters() can (and should) easily be added to all of the if-clauses here.

Apart from that, I'm okay with adding this.
2012-04-06 15:09:38 +02:00
..
Bridge [TwigBridge] Added a TwigEngine in the bridge 2012-04-02 18:28:35 +02:00
Bundle merged 2.0 2012-04-06 14:21:18 +02:00
Component merged branch jjbohn/feature/property-path-hasser (PR #3549) 2012-04-06 15:09:38 +02:00