Re: Re: Copying an Object
| From: | Daniel Kolbo | Date: | Fri, 24 Sep 2010 22:22:04 +0000 |
| Subject: | Re: 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-308308@lists.php.net to get a copy of this message | ||
On 9/24/2010 6:11 PM, Daniel Kolbo wrote:
> On 9/24/2010 8:35 AM, Peter Lind 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.
>>
>> Regards
>> Peter
>>
>
> I would consider the post to be a discussion among the community to
> discuss possible improvements for php, to help progress the language to
> handle the situations faced by the users of the language, and hey maybe
> learn something along the way. I certainly wouldn't consider the post
> to be an avenue to belittle members of the community. For some it's
> half empty, for others half full.
> `