Prev: ZipArchive, but without files
Next: module add on Suse 10.3
From: "Bob McConnell" on 24 Sep 2010 08:22
From: David Hutto

> On Fri, Sep 24, 2010 at 4:09 AM, Gary <php-general(a)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.

Bob McConnell
From: Peter Lind on 24 Sep 2010 08:35
On 24 September 2010 14:22, Bob McConnell <rvm(a)cbord.com> wrote:
> From: David Hutto
>
>> On Fri, Sep 24, 2010 at 4:09 AM, Gary <php-general(a)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.

Regards
Peter

--
<hype>
WWW: http://plphp.dk / http://plind.dk
LinkedIn: http://www.linkedin.com/in/plind
BeWelcome/Couchsurfing: Fake51
Twitter: http://twitter.com/kafe15
</hype>
From: "Bob McConnell" on 24 Sep 2010 09:05
From: Peter Lind

> On 24 September 2010 14:22, Bob McConnell <rvm(a)cbord.com> wrote:
>> From: David Hutto
>>
>>> On Fri, Sep 24, 2010 at 4:09 AM, Gary <php-general(a)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 have no problem with that idea. My first reaction would be to return to a procedural format and forget about objects altogether. I have been struggling with them for more than ten years now, and still don't understand the intent or purpose behind them. They simply appear to be a lot of unnecessary overhead with no real advantages in return. Even multi-tasking was a lot easier to figure out. Unfortunately, I keep getting stuck working with other people's applications that are already cast in objects. It makes me wish I could take early retirement this winter.

Sorry for the rant. I'll go hide in the corner and be quiet for a while.

Bob McConnell
From: chris h on 24 Sep 2010 09:05
On Fri, Sep 24, 2010 at 8:35 AM, Peter Lind <peter.e.lind(a)gmail.com> wrote:

> On 24 September 2010 14:22, Bob McConnell <rvm(a)cbord.com> wrote:
> > From: David Hutto
> >
> >> On Fri, Sep 24, 2010 at 4:09 AM, Gary <php-general(a)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.
>
> Regards
> Peter
>
> --
> <hype>
> WWW: http://plphp.dk / http://plind.dk
> LinkedIn: http://www.linkedin.com/in/plind
> BeWelcome/Couchsurfing: Fake51
> Twitter: http://twitter.com/kafe15
> </hype>
>
>


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.
From: "Bob McConnell" on 24 Sep 2010 09:34
From: chris h

> On Fri, Sep 24, 2010 at 8:35 AM, Peter Lind <peter.e.lind(a)gmail.com>
wrote:
>
> On 24 September 2010 14:22, Bob McConnell <rvm(a)cbord.com> wrote:
> > From: David Hutto
> >
> >> On Fri, Sep 24, 2010 at 4:09 AM, Gary
<php-general(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ZipArchive, but without files
Next: module add on Suse 10.3