Page 2 of 2
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 5:07 am
by Eran
VladSun wrote:I have no error/warning messages ...
error_reporting(E_ALL|E_STRICT); // error log file is empty
PHP Version 5.2.10
And I really think magic methods should be protected/private - one should not be able to run them directly.
It's a new notice in PHP 5.3+
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 6:10 am
by Weirdan
pytrin wrote:It's a new notice in PHP 5.3+
Warning to be precise:
Code: Select all
weirdan@virtual-debian:/home/sam/trunk$ php -r 'var_dump(phpversion()); class A { private function __call($a, $b) {var_dump($a, $b);} }; $q = new A; $q->qwe();'
Warning: The magic method __call() must have public visibility and cannot be static in Command line code on line 1
string(5) "5.3.1"
string(3) "qwe"
array(0) {
}
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 6:24 am
by VladSun
Blah, why it should be public??? It's purely internal usage object "method".
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 10:14 am
by alex.barylski
When job titles include "ninja" or "monkey" it raises a huge red flag to me. I won't lie and say its a deal breaker, but lets just say you offended me and aren't going to get as low of a salary should I accept. I'm a regular person, not a primate. It also shows (to me) you don't know any solid criteria to make hiring decisions on.
You realize that was the term provided by the OP in the opening topic I hope?
I hate silly names like 'monkey, ninja, cowboy, etc' to me they all indicate 'fly by the seat of your pants' programming. I prefer structured, organized and well planned. Engineer, analyst, consultant even. Silly names are a consequence of programming becoming so easy to get started in, the intelligence of monkey might actually result in something useful.
Cheers,
Alex
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 5:04 pm
by josh
VladSun wrote:Blah, why it should be public??? It's purely internal usage object "method".
Nah, what if I want $this->bar() to invoke __call, but don't want other people to see bar()? How would I set the visibility on a non-existent method otherwise?
It is true technically the Zend Engine is the one calling it ("internally") but you are looking at it as a white box.
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 6:58 pm
by VladSun
josh wrote:Nah, what if I want $this->bar() to invoke __call, but don't want other people to see bar()? How would I set the visibility on a non-existent method otherwise?
I don't get it - if __call has protected/private access, why $this->bar() can't invoke $this->__call - it has access to private/protected functions in the same class.
What do you mean by "set the visibility on a non-existent method"?
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:09 pm
by Eran
he means that since bar() is not a method on the object, __call() is the method getting called. It should be public in order to be called from outside the object instance in this manner. bar() does not invoke __call() since bar() does not exist
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:14 pm
by VladSun
My example (the one I've posted here) works, though __call is not public ...
__call shouldn't be called directly - that's my point. The only way one could achieve this is to make it protected/private.
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:17 pm
by josh
VladSun wrote:I don't get it - if __call has protected/private access, why $this->bar() can't invoke $this->__call - it has access to private/protected functions in the same class.
It would have access, that is the point. It would disallow collaborating objects from calling ->bar() outside the scope of the object (when I say non existent I mean overloaded or magic)
Instead of having to type
private function bar()
and making that delegate to a public call method, you could just make the call method private. That is why I assume they would add the feature. Lets say you wanted 1,000 protected methods. THe new feature allows you to do that with __call, without typing 1,000 method signatures.
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:30 pm
by VladSun
It's either my brain, or my poor English, but I really can't understand what you have in mind...
Are you saying that __call has to be protected/private or public?
Are we talking about the same behavior:
Code: Select all
class MyClass
{
public/protected/private function __call($m, $a)
{
echo "_call ";
}
public function bar()
{
echo "bar ";
}
protected function foo()
{
echo "foo ";
}
}
$var = new MyClass();
$var->none();
$var->bar();
$var->foo();
=>
?
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:39 pm
by josh
old way
Code: Select all
class MyClass
{
private function bar() {
return $this->__call('bar');
}
function __call()
{
return 'bar';
}
}
$obj->bar(); // error its private
new way
Code: Select all
class MyClass
{
private function __call()
{
return 'bar';
}
}
$obj->bar(); // error its private
Re: PHP OO Interviewee Test Questions
Posted: Tue Mar 02, 2010 7:50 pm
by VladSun
So, I should assume my misunderstanding is because my PHP version is 5.2.10 and yours is different???
Because the example I gave in my previous post didn't raise any error/warning/notice messages.
Re: PHP OO Interviewee Test Questions
Posted: Wed Mar 03, 2010 8:46 am
by alex.barylski
It's either my brain, or my poor English,
Oh come on, you speak better English than me and I grew up in a Anglo environment my entire life.

Re: PHP OO Interviewee Test Questions
Posted: Mon Apr 05, 2010 2:16 am
by josh
Google.. the next employer to look out for?

Re: PHP OO Interviewee Test Questions
Posted: Tue Apr 13, 2010 7:11 am
by Jenk
I wouldn't bother too much about actual code examples on paper, and stick with design on a whiteboard/flip-chart. The best interview I've had so far (as an interviewee), and usually use my self (as an interviewer) is have the usual chat with them in a meeting room, and then ask them some design questions relevant to my business. As it happens, we primarily write software for the logistics industry, and thus I ask an interviewee to draw* a design diagram that details the relationships between Depots, Vehicles, Containers, Drivers, Operators and Delivery Points. I will then ask them to describe what interfaces are used (with the aim of seeing if they spot the commonality between resources and importantly share the interface(s) relevant)
After this, they will then sit with an existing employee for 30mins to and hour and pair program with them. We started by letting them pair program on real work, but this turned out to be a bit too in the thick of it and the majority of the time was spent bringing them up to speed, so we developed a skeletal system (very simple) that we'd pair program together.
I don't think there is any substitute for finding out how someone will work within your company than to actually work with them, in your company.

No amount of exams or surveys will truly answer this.
*I don't care if it's UML, squiggly lines, or photo-like recreations, I just want clear design diagrams on the board
