I've actually thought a bit more about this and with the property->field mapping in UserService, I don't know that we even need to care about it honestly. In that situation, only the fields in the mapping are going into the query - so even if someone set $user->favoriteSpiceGirlsSong = "wannabe" - it wouldn't cause the query to fail…it would just silently judge them.

--  
Matt Frost
Sent with Sparrow (http://www.sparrowmailapp.com/?sig)


On Thursday, October 31, 2013 at 5:02 PM, Jeff Carouth wrote:

> In site/src/MentorApp/Tag.php:
> > + /** > + * @var \DateTime added The date\time the tag was added to the system > + */ > + public $added; > + > + /** > + * __set magic method to prevent additional properties from being set > + * this will override the default behavior of creating a new property > + * > + * @param string $name name of the property attempting to be set > + * @param string $value value of the property attempting to be set > + * @throws \Exception > + */ > + public function __set($name, $value) > + { > + throw new \Exception('You cannot set the unknown property: '.$name);  
> I appreciate the spirit of the __set() method in this and the User object, but you're really trying to fix PHP in userland here. If you want to go this route I would fall on @stevangoode (https://github.com/stevangoode)'s side and say you should trigger some sort of fatal error to simulate PHP actually caring about setting public properties that are not defined, whether an exception or simply using trigger_error() or whatever. That's my $0.02.
>  
> —
> Reply to this email directly or view it on GitHub (https://github.com/phpmentoring/mentor-app/pull/31/files#r7356579).
>  
>  
>