>> I dont think so, because nothing is declared private in the present
>> code.
>
> But they _might_ be as default in PHP5 ;-) That´s the really annoying
> difference between JAVA and C++, one is public by default, the other is
> private by default. I don´t know which approach they´ve chosen in PHP5, I
> would be surprised if they chose to do it different than C++, since these
> languages are very similar, syntax-wise, IE it´s public
>
>> The point of my post was to know if somebody knows a way to use this
>> approach consistently, without the oddities I've found while
>> programming.
>
> Inherit is the way to do it, the whole idea of OOPD is to give access to
> only the stuff the user needs:
>
> Class User {
> Function list_users(){}
> }
> Class Supervisor extends User {
> Function edit_users(){}
> }
> Class Admin extends Supervisor {
> Function delete_users(){}
> }
> Class Ceo extends Supervisor {
> Function sack_employee(){}
> }
>
Nice clear example, it very clearly shows the OOP design concept.
But (and there's always a but ;) real life problems are not so easy to
abstract all the time, and inevitable you always end "fixing something in
a rush" just to make it work (you know what I mean ;)
This doesn't mean you care little of the quality or security or speed of
your code, but as Lee Iacocca (GM's former ceo) used to say "don`t matter
how much information you collect before, to hit the duck you will almost
always end moving the rifle" (not exactly quote, but that's the idea).
So unless you go trough a strict programming cycle, defining precisely
prerequisites, use cases, identifying objects, etc, etc all things you
would expect more in a "serious" (read big) company, you (read I) just
write down the main objects I can think off, then write a couple of ideas
of what the client wants (read what I would want if I was him) and then
start writing some code.
In this my "OOPD killing" design approach :), 100% of the time is more
usefull to keep things all accesible so you can use them the second you
need them and rely in other means for access restriction (permissions,
etc).
Anyway, the way you mention is THE way to go, definitly, but you have that
little overhead of pre design tasks, that are not always worth, except in
big collaborative envs, etc.
> This way an instance of supervisor can list and edit users, but NOT delete
> them
> Admin can also delete them, but not fire any
> The CEO can fire a person, but not delete a user (for a number of reasons)
>
> YOU wanna give the user access to all, not good ;-)
>
>> Anyway thanks A LOT for your answers (and your time), I'll try php5 and
>> see what happens.
>
> No problem :-)
>
> /Kim
>
>
>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
