Restrict Calling Class.

[Michael Morris]

I have a Page class that creates out events. One of those is the UserAuth event, which gets a User entity object from the database and returns it to the page.

Now I want to protect the page's copy of the user object as much as possible, but writing has to be public to the UserAuth class or any class that extends it.

I know it's possible to see the calling function's class using debug_trace. My question is this - would using that to restrict access to the function be a good idea?

Hmm.. No - better idea.

public function setUserAuthModule ( UserAuthModule $userAuth) {
$this->userAuth = $userAuth;
}

And the userAuth module simple calls
$this->page->setUserAuthModule( $this );

I quite literally thought up that better approach while typing this up and it's sound. That said, would that prior idea ever be sane? I doubt it - it just feels like a clumsy means of trying to enforce "friend" status in PHP.

[TomB]

Seems odd to want to enforce this. If a class has an API why display a different API to certain objects?

Extend the class with the "hidden" function and pass that extended version to places you want to see it.

[Michael Morris]

Seems odd to want to enforce this. If a class has an API why display a different API to certain objects?

Extend the class with the "hidden" function and pass that extended version to places you want to see it.

Again, better just to have the userauth object pass itself, then I can use type hinting to insure the caller at the very least is sending an userauth object. I felt the debug tracing was a bad idea before I even started typing but typed all the same time and arrived at the proper idea. I figured it be amusing to hit send and show my insanity in action - I considered deleting the first post.

I don't even know why I had the idea - it doesn't seem like it could ever be useful - just confusing as hell to the maintenance programmer.