RE: [PHP] Re: Copying an Object
| From: | Bob McConnell | Date: | Fri, 24 Sep 2010 13:34:57 +0000 |
| Subject: | RE: [PHP] Re: Copying an Object | ||
| References: | 1 2 3 4 5 6 7 8 | Groups: | php.general |
| Request: | Send a blank email to php-general+get-308283@lists.php.net to get a copy of this message | ||
From: chris h
> On Fri, Sep 24, 2010 at 8:35 AM, Peter Lind <peter.e.lind@gmail.com>
wrote:
>
> On 24 September 2010 14:22, Bob McConnell <rvm@cbord.com> wrote:
> > From: David Hutto
> >
> >> On Fri, Sep 24, 2010 at 4:09 AM, Gary
<php-general@garydjones.name> wrote:
> >>> Daniel Kolbo wrote:
> >>>
> >>>> Say you have two classes: human and male. Further, say
male extends
> >>>> human. Let's say you have a human object. Then later you
want to make
> >>>> that human object a male object. This seems to be a pretty
reasonable
> >>>> thing to request of our objects.
> >>>
> >>> I don't think any human can change gender without major
surgery, but I
> >>> don't know if you just chose your example badly or whether
you really
> >>> think objects should be able to mutate into other types of
object
> >>> without some kind of special treatment.
> >>
> >> But it would work in something like makehuman, where you
start with a neuter
> >> form and scale one way or the other for physical features. If
I
> >> remember correctly,
> >> we're' all xx until you become xy(genetically speaking).
> >
> > This is one of the details that really bothers me about OOP.
It makes
> it impossible to implement some very reasonable scenarios. 80% of the
time,
> when a patron is added to a system, we don't know which gender they
are.
> More than 50% of the time, we will never know, since the client
doesn't keep
> track of it. But the rest of them will be assigned sometime after they
were
> added. i.e. the gender assignment comes from a secondary source that
is not
> available at the time the patron is entered.
> >
> If you can't handle that, it's not the fault of OOP but your
lack of
> programming skills in OOP I'd say (and I mean no disrespect
there, I'm
> just pretty sure your scenario can be handled very easily in
OOP).
>
> And no, I have no urge to defend OOP in PHP, I just see this
entire
> thread as a complete non-starter: if the language doesn't let
you do
> something in a particular way, how about you stop, take a
breather,
> then ask if perhaps there's a better way in the language to do
what
> you want done? That would normally be a much more productive and
> intelligent response than either a) pressing on in the face of
failure
> or b) complaining about your specific needs and how the language
fails
> to meet them.
>
> I think pages 17-19 of the GoF covers exactly this:
>
> "Object composition is an alternative to inheritance." ... "Any
> [composed] object can be replaced at run-time by another as long
> as it has the same type."
>
> I would look into "object composition" or just read the GoF.
GoF?
Bob McConnell