php-general Digest 8 Feb 2012 14:10:02 -0000 Issue 7680

Topics (messages 316549 through 316553):

Re: What's Your Favorite Design Pattern?
        316549 by: Paul M Foster
        316550 by: Alejandro Michelin Salomon
        316552 by: Tommy Pham

Re: Arrays: Comma at end?
        316551 by: Ghodmode

PhpBrew is released
        316553 by: Lin Yo-An

Administrivia:

To subscribe to the digest, e-mail:
        php-general-digest-subscr...@lists.php.net

To unsubscribe from the digest, e-mail:
        php-general-digest-unsubscr...@lists.php.net

To post to the list, e-mail:
        php-gene...@lists.php.net


----------------------------------------------------------------------
--- Begin Message ---
On Tue, Feb 07, 2012 at 09:02:00PM +0000, Tim Streater wrote:

> On 07 Feb 2012 at 19:34, Daniel Brown <danbr...@php.net> wrote: 
> 
> > On Tue, Feb 7, 2012 at 13:56, Mike Mackintosh
> > <mike.mackint...@angrystatic.com> wrote:
> >> I was curious to see what everyones favorite design patterns were, if you 
> >> use
> >> any, and why/when have you used it?
> >>
> >> Choices include slots and signals (observer), singleton, mvc, hmvc, 
> >> factory,
> >> commander etc..
> >
> >    Mine is apparently CPSV (Commentless Procedural Spaghetti Vomit),
> > as that's what I encounter no less than 80% of the time in the wild.
> 
> Since I have no idea what anyone is talking about, I can only conclude that 
> you're playing Mornington Crescent (q.v.), on a non-standard board.
> 
> --
> Cheers  --  Tim
> 

Design Patterns are Way Nifty Kewl patterns of code which are supposed
to facilitate certain types of operations. (Was that sarcasm you
detected? Yes it was.)

For example, the Singleton pattern. Let's say you had a configuration
class that held the configuration values for your application, and you
wanted to make sure there was only one object of that class
instantiated, no matter how many times it was called in your code. You'd
arrange the code and call the class in a certain way to ensure that only
one object of that class resulted. To make your configuration class a
"singleton", you'd probably make the class have a *private* constructor
(so no outside routine could call it), and then provide a method called
get_instance() which tested for the existence of an object of that
class. If such an instance was found, someone calling
configuration::get_instance() would simply get the existing object
returned to them. Otherwise, configuration::get_instance() would
instantiate the class and then return the new object to the caller.

As you can see, that's a peculiar way of setting up your code for a
specific purpose. Other design patterns do other things and dictate
setting up things in other ways.

The definitive work on this (and where it first gained the most
publicity) is a book called "Design Patterns" by four authors (Gamma,
Helm, Johnson and Vlissides). It essentially contains a chapter about
each (known at the time) design pattern and some pseudocode about how it
might be constructed. I imagine the authors looked at a lot of code and
discovered that programmers were coming up with code that, in each case
was remarkably similar for solving certain types of programming
problems. So they codified what that found and wrote a book about it.

I have the book on my shelf, and it's decent technology, but you could
spend your whole career and never use any of it, and get along just
fine. 

Paul

-- 
Paul M. Foster
http://noferblatz.com
http://quillandmouse.com

--- End Message ---
--- Begin Message ---
Mike:

My favorite are singleton ( database connection configuration ), and
factory.

Factory i use when need one code exporting or doing different process. 

Basically y have a base class with general code and a specific class that
extend the base class with code specific to the process to be made.
The main code only pass the type of format ant factory returns de right code
for the operation.

The main code remains untouched, when the factory chance each time a i need
other type of process or exportation results.

Alejandro M.S.

-----Mensagem original-----
De: Mike Mackintosh [mailto:mike.mackint...@angrystatic.com] 
Enviada em: terça-feira, 7 de fevereiro de 2012 16:57
Para: PHP General List
Assunto: [PHP] What's Your Favorite Design Pattern?

I was curious to see what everyones favorite design patterns were, if you
use any, and why/when have you used it?

Choices include slots and signals (observer), singleton, mvc, hmvc, factory,
commander etc..

Thanks,

--
Mike Mackintosh
PHP, the drug of choice - www.highonphp.com





--- End Message ---
--- Begin Message ---
On Tue, Feb 7, 2012 at 2:31 PM, Paul M Foster <pa...@quillandmouse.com> wrote:
> On Tue, Feb 07, 2012 at 09:02:00PM +0000, Tim Streater wrote:
>
>> On 07 Feb 2012 at 19:34, Daniel Brown <danbr...@php.net> wrote:
>>
>> > On Tue, Feb 7, 2012 at 13:56, Mike Mackintosh
>> > <mike.mackint...@angrystatic.com> wrote:
>> >> I was curious to see what everyones favorite design patterns were, if you 
>> >> use
>> >> any, and why/when have you used it?
>> >>
>> >> Choices include slots and signals (observer), singleton, mvc, hmvc, 
>> >> factory,
>> >> commander etc..
>> >
>> >    Mine is apparently CPSV (Commentless Procedural Spaghetti Vomit),
>> > as that's what I encounter no less than 80% of the time in the wild.
>>
>> Since I have no idea what anyone is talking about, I can only conclude that 
>> you're playing Mornington Crescent (q.v.), on a non-standard board.
>>
>> --
>> Cheers  --  Tim
>>
>
> Design Patterns are Way Nifty Kewl patterns of code which are supposed
> to facilitate certain types of operations. (Was that sarcasm you
> detected? Yes it was.)
>
> For example, the Singleton pattern. Let's say you had a configuration
> class that held the configuration values for your application, and you
> wanted to make sure there was only one object of that class
> instantiated, no matter how many times it was called in your code. You'd
> arrange the code and call the class in a certain way to ensure that only
> one object of that class resulted. To make your configuration class a
> "singleton", you'd probably make the class have a *private* constructor
> (so no outside routine could call it), and then provide a method called
> get_instance() which tested for the existence of an object of that
> class. If such an instance was found, someone calling
> configuration::get_instance() would simply get the existing object
> returned to them. Otherwise, configuration::get_instance() would
> instantiate the class and then return the new object to the caller.
>
> As you can see, that's a peculiar way of setting up your code for a
> specific purpose. Other design patterns do other things and dictate
> setting up things in other ways.
>

Here's a code example of the above explanation:

http://pastebin.com/mTrybi6u

HTH,
Tommy


> The definitive work on this (and where it first gained the most
> publicity) is a book called "Design Patterns" by four authors (Gamma,
> Helm, Johnson and Vlissides). It essentially contains a chapter about
> each (known at the time) design pattern and some pseudocode about how it
> might be constructed. I imagine the authors looked at a lot of code and
> discovered that programmers were coming up with code that, in each case
> was remarkably similar for solving certain types of programming
> problems. So they codified what that found and wrote a book about it.
>
> I have the book on my shelf, and it's decent technology, but you could
> spend your whole career and never use any of it, and get along just
> fine.
>
> Paul
>
> --
> Paul M. Foster
> http://noferblatz.com
> http://quillandmouse.com
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>

--- End Message ---
--- Begin Message ---
On Wed, Feb 8, 2012 at 4:10 AM, Ashley Sheridan
<a...@ashleysheridan.co.uk> wrote:
> On Tue, 2012-02-07 at 11:50 -0800, Micky Hulse wrote:
>
>> Was there ever a time when having a comma at the end of the last array
>> element was not acceptable in PHP?
...
> It's fine in PHP, and some coding practices actually encourage it, for
> example:
...
>
> It's easy to add and remove elements without making sure you have to
> check the trailing comma. It's also OK in Javascript to use the trailing
> comma, as long as you don't mind things not working on IE, which is the
> only browser that has issues with it. As far as PHP goes though, it's
> fine.

I believe this behavior was inherited from Perl.  I used Perl before I
used PHP and it was considered a feature for exactly the reason Ash
gave.

I think that problems with Perl may have originally inspired the
creation of PHP, at least in part.  But they kept the good parts.
This is just my perception.  To confirm it, I'd have to ask our BDFL
:)

--
Vince Aggrippino
a.k.a. Ghodmode
http://www.ghodmode.com


> --
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>

--- End Message ---
--- Begin Message ---
Hi folks,

phpbrew builds and installs multiple version php(s) in your $HOME directory.

phpbrew is like php-build , but phpbrew also manage the environment
variables,
so you can switch php version whenever you need.

phpbrew is on GitHub: https://github.com/c9s/phpbrew

patches are welcomed.



Best Regards,

Yo-An Lin (c9s)

GitHub: https://github.com/c9s

--- End Message ---

Reply via email to