Re: [PHP] Re: OOP Hello World

2006-10-05 Thread John Wells

On 10/5/06, Martin Alterisio <[EMAIL PROTECTED]> wrote:

The kind of thinking that OOP it's just a *super* feature of a programming
language that should be used only for highly complex problems, is what I
want to eradicate. OOP doesn't stand neither as a language feature nor as
extra capabilities of a language, on the contrary, it takes some freedom
away from the programmer. I see OOP as a way of thinking and working, that
should be used in the most complex problem and the most simple problem
equally.


Err.  OOP came about exclusively as a way to manage complexity.   I'm
not so sure about making a simple problem complex just so you can
simplify it with OOP.  And it *is* only a feature of PHP.  So unlike
other languages, you actually *do* have a choice.

Of course I LOVE having the choice, which is why I LOVE PHP.  I get so
much out of POOPH every time I dive into it.


Nope, I caught your joke, and I found it amusing. Though every joke hides a
truth, as I can explain a hello world in oop laughing and being serious at
the same time.


My ex girlfriend always used that line on me.  Drove me mad.  :P

I wish we could continue this over a round of beers at the pub.  I
think we'd have fun batting this back and forth.  :)  And we won't
fill up The List's inbox in the process.

Cheers,
John W

--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php



Re: [PHP] Re: OOP Hello World

2006-10-05 Thread Martin Alterisio

2006/10/5, John Wells <[EMAIL PROTECTED]>:


On 10/5/06, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> PHP seems to be getting more and more object oriented, I think it's the
> right time to start questioning what have been done so far in terms of
OOP
> in PHP, because, honestly, there are too many php classes being
distributed
> out there that are a complete mess. Forget about spaghethi code, we have
to
> deal with pizza classes too.

[code]
require_once('previousEmails.php');

interface Responder {
public function respond(Salutable $receiver, $response);
public function getResponderName();
}

class WiseAssResponder implements Responder {
protected $responderName;

public function __construct($responderName) {
$this->responderName = $responderName;
}

public function getResponderName() {
return $this->responderName;
}

public function respond(Salutable $receiver, $response) {
echo "Hi " . $receiver->getSalutationName()
   . ".  Please read my response
below: \n\n";
echo $response;
echo "Kindest Regards,\n" .
$this->getResponderName();
}
}

class Martin implements Salutable {
public function getSalutationName() {
return get_class($this);
}
}

$martin = new Martin();
$johnW = new WiseAssResponder('John W');
$response=<<


I'd rather say that we have different concepts of what is simple and
flexible, and both concepts are aceptable.

I know that plenty of people on this list want to have a serious

conversation about OOP for PHP (should we just start using OOPHP as
the new acronym?  or maybe POOPH?  Or... PHOOP?!? Wait, that's not
taking thing seriously...), but I don't think a complex Hello, World
made of Saluters, Salutables, factories and abstractions is taking it
serious.  I think it's exhausting the theory and using various design
patterns for the sake of using design patterns...



It seems we've differents approaches to what is complex and what is simple
(in terms of computer systems). I think being serious about OOP is start
thinking even the simplest of problem from an OOP perspective. I just
exposed the Hello World as an example, off course it seems like using a nuke
to kill a mosquito, but here I'm not thinking about efficiency or efficacy,
it's about training the mind into the OOP methodologies and ways of
thinking. Like training your body, once the mind sees everything in terms of
object abstraction, OOP will be as natural as breathing.

The kind of thinking that OOP it's just a *super* feature of a programming
language that should be used only for highly complex problems, is what I
want to eradicate. OOP doesn't stand neither as a language feature nor as
extra capabilities of a language, on the contrary, it takes some freedom
away from the programmer. I see OOP as a way of thinking and working, that
should be used in the most complex problem and the most simple problem
equally.

But really all of this comes down to the imutable truth about

programming in PHP: there are a *million* ways to skin a cat.  When
you heard "OOP + Hello, World", you thought about people/things
greeting each other.  When I heard it, I thought about an application
outputing a string.  The guy who started that particular thread
probably thought of something totally different.  Who's to say who is
right?



Off course, no one can say which is the right way to solve a problem, and I
will not hide the fact that OOP is just a coder's whim. I'm just inviting
you over to this whim, I can assure you that it's a healthy and beneficial
whim, it's not just a Java hype. At least it's healthier whim than web2.0.

Hey, take my words as mine alone though.  Maybe I was the only one

that got my joke.  It's happened before.



Nope, I caught your joke, and I found it amusing. Though every joke hides a
truth, as I can explain a hello world in oop laughing and being serious at
the same time.

HEREDOC;


$johnW->respond($martin, $response);
exit;
[/code]



Re: [PHP] Re: OOP Hello World

2006-10-05 Thread John Wells

On 10/5/06, Martin Alterisio <[EMAIL PROTECTED]> wrote:

PHP seems to be getting more and more object oriented, I think it's the
right time to start questioning what have been done so far in terms of OOP
in PHP, because, honestly, there are too many php classes being distributed
out there that are a complete mess. Forget about spaghethi code, we have to
deal with pizza classes too.


[code]
require_once('previousEmails.php');

interface Responder {
public function respond(Salutable $receiver, $response);
public function getResponderName();
}

class WiseAssResponder implements Responder {
protected $responderName;

public function __construct($responderName) {
$this->responderName = $responderName;
}

public function getResponderName() {
return $this->responderName;
}

public function respond(Salutable $receiver, $response) {
echo "Hi " . $receiver->getSalutationName()
   . ".  Please read my response below: 
\n\n";
echo $response;
echo "Kindest Regards,\n" . $this->getResponderName();
}
}

class Martin implements Salutable {
public function getSalutationName() {
return get_class($this);
}
}

$martin = new Martin();
$johnW = new WiseAssResponder('John W');
$response=<

Re: [PHP] Re: OOP Hello World

2006-10-05 Thread Martin Alterisio

Double-checking.

Nope.

It wasn´t from the Java mailing list, they're still talking about
hibernate... they'll probably give a damn about this thing anyway, because
they're all oop gurus, what would they care about a hello world?

PHP seems to be getting more and more object oriented, I think it's the
right time to start questioning what have been done so far in terms of OOP
in PHP, because, honestly, there are too many php classes being distributed
out there that are a complete mess. Forget about spaghethi code, we have to
deal with pizza classes too.

2006/10/5, John Wells <[EMAIL PROTECTED]>:


Are you sure you're not on a Spanish *Java* mailing list?

:)

On 10/5/06, Martin Alterisio <[EMAIL PROTECTED]> wrote:
> Me... again, still boring you to death with meaningless OOP rantings.
>
> First I would like to point out that there was a design mistake in what
I
> proposed in the last mail (following afterwards): the Saluter shouldn't
be
> an abstract class, it isn't correct to base your class hierarchy on the
> ability to greet (or in the ability to do something generally speaking).
If
> it's done that way we'll have classes coexisting in the same branch of
the
> class tree, but possibly having completely different nature. Saluter
should
> be an interface:
>
>   interface class Saluter {
> public function greet(Salutable $receiver);
>   }
>
>   class FormalSaluter implements Saluter {
> public function greet(Salutable $receiver) {
>   echo "Hello " . $receiver->getSalutationName() . "\n";
> }
>   }
>
> Then, I'll try to translate what has been said in the spanish list.
>
> It has been proposed that World should be a singleton, since there is
only
> one world... but this arguable, at metaphysic level perhaps...
>
> Also an observer pattern could be used so anyone can hear the greetings.
But
> I think this should be done on the design of the greeting enviroment
> abstraction (to provide other places than standard output where the
greeting
> can be said).
>
> The saluters factory should use a factory method pattern or an abstract
> factory pattern? I think an abstract factory is not appropiate in this
case,
> the creation process is not that complex to require this kind of design
> pattern.
>
> Also I proposed that decorators could be used to add styles to the
greeting
> for outputs that allow styling (e.g.:html). In this case maybe an
abstract
> factory would be appropiate, so that decorated saluters are created for
the
> appropiate type of output, combined with a builder pattern to create the
> decorated saluters (this last part I thought it just now, I'll post it
later
> on the spanish list)
>
> Well, I think that sums it all up.
>
> 2006/9/29, Martin Alterisio <[EMAIL PROTECTED]>:
> >
> > What's up folks?
> >
> > I just wanted to tell you about a thread that's going on in the
spanish
> > php mailing list. A fellow software developer which had just started
with
> > OOP was asking for "Hello World" examples using OOP. The examples of
code he
> > had been doing was not that different from the usual Hello World
example we
> > all know and love(?), so I thought he was missing the point of what
was the
> > purpose of using OOP. This was my reply (I'll try to keep the
translation as
> > accurate as possible):
> >
> > I believe you have misunderstood what is the purpose of OOP, your
objects
> > are not proper abstractions.
> >
> > First and most important, you should define what is the problem to
solve:
> > greet the world.
> > We build an abstraction of the problem and its main components:
somebody
> > who greets and something to greet.
> > Here we're working with generalizations, since our main objective is
to
> > build reusable objects. For that purpose is useful that our "saluter"
could
> > be used to greet more than just the world.
> >
> > Therefore we'll first define what kind of interaction we expect the
> > salutation receivers to have, in the following interface:
> >
> >   interface Salutable {
> > public function getSalutationName();
> >   }
> >
> > In this interface we have all we need to properly greet any entity:
the
> > name we should use when doing the salutation.
> >
> > Then we create the object which represents the world:
> >
> >   class World implements Salutable {
> > public function getSalutationName() {
> >   return "World";
> > }
> >   }
> >
> > Now we're missing a saluter, but we're not sure which way of greeting
> > would be appropiate, so we prefer to create an abstract saluter and
leave
> > the child implementation to decide the appropiate greeting:
> >
> >   abstract class Saluter {
> > abstract public function greet(Salutable $receiver);
> >   }
> >
> > In our case we need a formal saluter as we should not disrespect the
world
> > (saying "hey! wazzup world?" could be offensive), then:
> >
> >   class FormalSaluter extends Saluter {
> > public function greet(Salutable $receiver) {
> >   echo "Hello " . $receiver->getSalutationName() . 

Re: [PHP] Re: OOP Hello World

2006-10-05 Thread John Wells

Are you sure you're not on a Spanish *Java* mailing list?

:)

On 10/5/06, Martin Alterisio <[EMAIL PROTECTED]> wrote:

Me... again, still boring you to death with meaningless OOP rantings.

First I would like to point out that there was a design mistake in what I
proposed in the last mail (following afterwards): the Saluter shouldn't be
an abstract class, it isn't correct to base your class hierarchy on the
ability to greet (or in the ability to do something generally speaking). If
it's done that way we'll have classes coexisting in the same branch of the
class tree, but possibly having completely different nature. Saluter should
be an interface:

  interface class Saluter {
public function greet(Salutable $receiver);
  }

  class FormalSaluter implements Saluter {
public function greet(Salutable $receiver) {
  echo "Hello " . $receiver->getSalutationName() . "\n";
}
  }

Then, I'll try to translate what has been said in the spanish list.

It has been proposed that World should be a singleton, since there is only
one world... but this arguable, at metaphysic level perhaps...

Also an observer pattern could be used so anyone can hear the greetings. But
I think this should be done on the design of the greeting enviroment
abstraction (to provide other places than standard output where the greeting
can be said).

The saluters factory should use a factory method pattern or an abstract
factory pattern? I think an abstract factory is not appropiate in this case,
the creation process is not that complex to require this kind of design
pattern.

Also I proposed that decorators could be used to add styles to the greeting
for outputs that allow styling (e.g.:html). In this case maybe an abstract
factory would be appropiate, so that decorated saluters are created for the
appropiate type of output, combined with a builder pattern to create the
decorated saluters (this last part I thought it just now, I'll post it later
on the spanish list)

Well, I think that sums it all up.

2006/9/29, Martin Alterisio <[EMAIL PROTECTED]>:
>
> What's up folks?
>
> I just wanted to tell you about a thread that's going on in the spanish
> php mailing list. A fellow software developer which had just started with
> OOP was asking for "Hello World" examples using OOP. The examples of code he
> had been doing was not that different from the usual Hello World example we
> all know and love(?), so I thought he was missing the point of what was the
> purpose of using OOP. This was my reply (I'll try to keep the translation as
> accurate as possible):
>
> I believe you have misunderstood what is the purpose of OOP, your objects
> are not proper abstractions.
>
> First and most important, you should define what is the problem to solve:
> greet the world.
> We build an abstraction of the problem and its main components: somebody
> who greets and something to greet.
> Here we're working with generalizations, since our main objective is to
> build reusable objects. For that purpose is useful that our "saluter" could
> be used to greet more than just the world.
>
> Therefore we'll first define what kind of interaction we expect the
> salutation receivers to have, in the following interface:
>
>   interface Salutable {
> public function getSalutationName();
>   }
>
> In this interface we have all we need to properly greet any entity: the
> name we should use when doing the salutation.
>
> Then we create the object which represents the world:
>
>   class World implements Salutable {
> public function getSalutationName() {
>   return "World";
> }
>   }
>
> Now we're missing a saluter, but we're not sure which way of greeting
> would be appropiate, so we prefer to create an abstract saluter and leave
> the child implementation to decide the appropiate greeting:
>
>   abstract class Saluter {
> abstract public function greet(Salutable $receiver);
>   }
>
> In our case we need a formal saluter as we should not disrespect the world
> (saying "hey! wazzup world?" could be offensive), then:
>
>   class FormalSaluter extends Saluter {
> public function greet(Salutable $receiver) {
>   echo "Hello " . $receiver->getSalutationName() . "\n";
> }
>   }
>
> Finally we make our saluter greet the world:
>
>   $saluter = new FormalSaluter();
>   $world = new World();
>   $saluter->greet($world);
>
> 
>
> Other things you should keep in mind:
>
> * PHP's type hinting is preety limited, in this case we would like to
> indicate that the name should be provided as a string but we can't. Maybe it
> would be useful to use an object as a wrapper for native strings. EDIT: I
> remembered while translating this that type hinting can only be used in
> function parameters, therefore this point is useless.
>
> * En this model it seems more appropiate that the saluter is an abstract
> class, since salutation works one way, but, in the event salutations became
> a two way trip, an interface would be more appropiate for the salute