On 25 September 2010 00:11, Daniel Kolbo <dkolbo@xxxxxxxxx> wrote:
> On 9/24/2010 8:35 AM, Peter Lind wrote:
>> On 24 September 2010 14:22, Bob McConnell <rvm@xxxxxxxxx> wrote:
>>> From: David Hutto
>>>
>>>> On Fri, Sep 24, 2010 at 4:09 AM, Gary <php-general@xxxxxxxxxxxxxxx> 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.
> `
I apologize for the wording of my post - I did not intend to belittle anyone.
Your posts seem to me, however, rather typical: "I am coming up
against this problem, why doesn't the language let me solve it the way
I want it to?" - something this last response also suggests ("I would
consider the post to be a discussion among the community to discuss
possible improvements for php"). Many people have already pointed out
that there's likely a much better solution to the problem at hand, yet
you still insist that the language should be improved (the latest idea
being a __cast() function) - and I cannot see you once commenting on
the composition strategy. Was the "... and hey maybe learn something
along the way." meant only for others?
Anyway, seeing as my glass is half-empty and I'm not adding anything
constructive to thread I'll refrain from posting more.
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>
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
