Prev: ZipArchive, but without files
Next: module add on Suse 10.3
From: chris h on 24 Sep 2010 09:49
"Gang of Four"

http://www.amazon.com/Design-Patterns-Elements-Reusable-Object-Oriented/dp/0201633612

An excellent book on OOP.

Chris H.


On Fri, Sep 24, 2010 at 9:34 AM, Bob McConnell <rvm(a)cbord.com> wrote:

> 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
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
From: Nathan Nobbe on 24 Sep 2010 13:29
On Thu, Sep 23, 2010 at 12:24 AM, Peter Lind <peter.e.lind(a)gmail.com> wrote:

> On 23 September 2010 02:14, Daniel Kolbo <kolb0057(a)umn.edu> wrote:
>
> *snip*
>
> > On 9/22/2010 9:11 AM, chris h 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.
>
> Perhaps if you're a C# programmer, but the PHP way of thinking is
> radically different.
> C#: This object is whatever it was currently cast to (if possible)
> PHP: This object is this object, whatever it was created as
>
> If you have a need to make an object switch class in PHP, then there's
> a 99% chance you're working against, not with the language.
>

+1, its more like the java paradigm than anything else afaict. maybe
javascript? didnt know you could change class at runtime in c#, but then
again my knowledge of the .net platform is very, very minimal, and happily
so :)

getting to some of the other posts in the thread and trying to find a
reasonable place to address them, id like to point out that this scenario
(turning a human into a male) is easily modeled w/ composition in oop.

class Human
{
// member vars & functions here
}

class Male
{
$human = null; // Human instance

__construct(Human $human)
{
$this->human = $human;
}
}

javascript uses a form of inheritance called prototypical inheritance.

http://en.wikipedia.org/wiki/Prototype-based_programming

and other languages that support runtime class alteration (ruby, python,
objc etc.) are quite different than the single inheritance model in php.
that said, there are ways of modeling this problem in any of these
languages (see above for 1 reasonable solution w/ single inheritance in
php). one of the problems w/ the runtime class alteration model is how do
you determine the class of an object after altering it at runtime?

-nathan
From: Daniel Kolbo on 24 Sep 2010 18:19

>
> On 9/24/2010 4:09 AM, Gary 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.
>>
>>> This type of thing would especially be
>>> easy if objects of parent classes could be cast as an object of its
>>> extended class.
>>
>> Where would the extra data come from to fill in any fields the base
>> class does not have? Just think of a simple example with a Shape class,
>> extended by a ColouredShape class which contains some data about the
>> object's colour - if you have a Shape object it can't become a
>> ColouredShape without some surgery because bits of the ColouredShape's
>> anatomy are not present.
>>
>> --
>> Gary Please do NOT send me 'courtesy' replies off-list.
>> PHP 5.2.12 (cli) (built: Jan 14 2010 14:54:11)
>> 1.7.7(0.230/5/3) 2010-08-31 09:58 Cygwin
>>
>>
>
> The colouredShape class would probably have a member variable called
> $color. This member could have a default value (as defined in the
> class), be defined through the __construct() method (which would be
> invoked upon such a cast procedure...perhaps there could be a __cast()
> method much like how there is a __clone() method.
From: Daniel Kolbo on 24 Sep 2010 18:22
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(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
>>
>
> 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.
> `

From: Peter Lind on 25 Sep 2010 02:51
On 25 September 2010 00:11, Daniel Kolbo <dkolbo(a)gmail.com> wrote:
> On 9/24/2010 8:35 AM, Peter Lind 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
>>
>
> 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>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: ZipArchive, but without files
Next: module add on Suse 10.3