php-general Digest 1 Feb 2011 05:53:26 -0000 Issue 7161
Topics (messages 311094 through 311107):
Re: odd list bounces
311094 by: Shreyas Agasthya
311096 by: Richard Quadling
311097 by: Nicholas Kell
311098 by: Daniel Brown
Re: "public static" or "static public"?
311095 by: Richard Quadling
311099 by: Bob McConnell
311100 by: David Harkness
311101 by: Mujtaba Arshad
Code formatter
311102 by: Hansen, Mike
311103 by: Jonesy
311104 by: Hansen, Mike
311106 by: Ken Guest
Vermis 1.0 r130 The Issue Tracking System based on ZF and Doctrine
311105 by: Lukasz Cepowski
Detecting Multi-Scope Variables
311107 by: Brad Lorge
Administrivia:
To subscribe to the digest, e-mail:
[email protected]
To unsubscribe from the digest, e-mail:
[email protected]
To post to the list, e-mail:
[email protected]
----------------------------------------------------------------------
--- Begin Message ---
Ashley,
I just got one with the subject line as : ' ezmlm warning'
*
*
On Mon, Jan 31, 2011 at 4:17 PM, Ashley Sheridan
<[email protected]>wrote:
> Hiya,
>
> Is anyone else getting odd bounce messages? I just received one from the
> list about a message that was returned as a bounce from my email
> address. The fact that I was able to read an email about an email that
> bounced from me suggests that things are OK my end with regards to
> receiving messages.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
>
--
Regards,
Shreyas Agasthya
--- End Message ---
--- Begin Message ---
On 31 January 2011 10:52, Shreyas Agasthya <[email protected]> wrote:
> Ashley,
>
> I just got one with the subject line as : ' ezmlm warning'
> *
> *
>
> On Mon, Jan 31, 2011 at 4:17 PM, Ashley Sheridan
> <[email protected]>wrote:
>
>> Hiya,
>>
>> Is anyone else getting odd bounce messages? I just received one from the
>> list about a message that was returned as a bounce from my email
>> address. The fact that I was able to read an email about an email that
>> bounced from me suggests that things are OK my end with regards to
>> receiving messages.
>>
>> Thanks,
>> Ash
>> http://www.ashleysheridan.co.uk
>>
>>
>>
>
>
> --
> Regards,
> Shreyas Agasthya
>
I got 1 bounce for this message.
http://news.php.net/php.general/310871
Dan's feeding someone who is already overstuffed.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
On Jan 31, 2011, at 4:47 AM, Ashley Sheridan wrote:
> Hiya,
>
> Is anyone else getting odd bounce messages? I just received one from the
> list about a message that was returned as a bounce from my email
> address. The fact that I was able to read an email about an email that
> bounced from me suggests that things are OK my end with regards to
> receiving messages.
>
> Thanks,
> Ash
> http://www.ashleysheridan.co.uk
>
>
I received one too.
Message 310871 was the bouncer for me.
--- End Message ---
--- Begin Message ---
On Mon, Jan 31, 2011 at 09:10, Nicholas Kell <[email protected]> wrote:
>
> I received one too.
> Message 310871 was the bouncer for me.
Yeah, it's because most mail servers didn't like the number of
suspicious terms coupled with the bounce. It was directed at Merlin
(as in, "hey, your mailbox is full, so you won't hear anything we have
to say anyway") and CC'ed to the list, as per the norm, to allow him
to see that message as well. The majority of the bounces were from
Gmail or Google-hosted email accounts.
--
</Daniel P. Brown>
Network Infrastructure Manager
Documentation, Webmaster Teams
http://www.php.net/
--- End Message ---
--- Begin Message ---
On 28 January 2011 17:15, Colin Guthrie <[email protected]> wrote:
> OK, so it's a Friday hence a random debate....
>
>
> What is preferred for class methods?
>
> class foo
> {
> static public function bar(){}
>
> public static function wibble(){}
> }
>
> ??
>
> All methods are valid, but are some more valid than others? :p
>
> Checking ZF:
>
> [colin@jimmy Zend (working)]$ cgrep "public static function" . |wc -l
> 755
> [colin@jimmy Zend (working)]$ cgrep "static public function" . |wc -l
> 60
>
> It's clear which is preferred there, but still not absolutely consistent
> (I didn't bother checking differently scoped methods).
>
>
> I personally prefer scope first then "static", but others may have valid
> reasons/arguments for preferring the other way.
>
> WDYT?
>
> Col
>
>
>
> --
>
> Colin Guthrie
> gmane(at)colin.guthr.ie
> http://colin.guthr.ie/
>
> Day Job:
> Tribalogic Limited [http://www.tribalogic.net/]
> Open Source:
> Mageia Contributor [http://www.mageia.org/]
> PulseAudio Hacker [http://www.pulseaudio.org/]
> Trac Hacker [http://trac.edgewall.org/]
>
>
> --
> PHP General Mailing List (http://www.php.net/)
> To unsubscribe, visit: http://www.php.net/unsub.php
>
>
Arrange these 3 words in the "correct" linguistic.
shirt, large, green.
Hopefully, all native English speakers will say
large green shirt.
We just do.
I wonder if the same is true for ...
final public static function
I've just done a quick scan of all my methods ...
5 abstract protected function
2 abstract public function
2 final protected function
11 final public function
1 final public static function
1 final static public function
2 private final function
12 private function
8 private static function
120 protected function
5 public final function
125 public function
11 public static function
3 static function
4 static private function
7 static protected function
16 static public function
This is code that is 6 years old. As you can see I'm completely inconsistent.
If there was some evidence that one order is preferable to another -
pretty much ANY metric would do - then I'd probably adopt it.
But I don't know if it makes ANY difference.
OOI. I did the same analysis for Zend Framework (not the most recent,
but a good a representative analysis as any I suppose).
1 abstract function
40 abstract protected function
153 abstract public function
1 final private function
1 final protected function
9 final public function
2 final public static function
150 private function
37 private static function
1 protected abstract function
1507 protected function
63 protected static function
5 public abstract function
2 public final function
11956 public function
701 public static function
1 static function
1 static private function
10 static protected function
60 static public function
So, as mixed up as my own.
Richard.
--
Richard Quadling
Twitter : EE : Zend
@RQuadling : e-e.com/M_248814.html : bit.ly/9O8vFY
--- End Message ---
--- Begin Message ---
From: Richard Quadling
> On 28 January 2011 17:15, Colin Guthrie <[email protected]> wrote:
>> OK, so it's a Friday hence a random debate....
>>
>> What is preferred for class methods?
>>
>> class foo
>> {
>> static public function bar(){}
>>
>> public static function wibble(){}
>> }
>>
>> ??
>>
>> All methods are valid, but are some more valid than others? :p
>>
>> Checking ZF:
>>
>> [colin@jimmy Zend (working)]$ cgrep "public static function" . |wc -l
>> 755
>> [colin@jimmy Zend (working)]$ cgrep "static public function" . |wc -l
>> 60
>>
>> It's clear which is preferred there, but still not absolutely consistent
>> (I didn't bother checking differently scoped methods).
>>
>>
>> I personally prefer scope first then "static", but others may have valid
>> reasons/arguments for preferring the other way.
>>
>> WDYT?
>>
>
> Arrange these 3 words in the "correct" linguistic.
>
> shirt, large, green.
>
> Hopefully, all native English speakers will say
>
> large green shirt.
>
> We just do.
>
> I wonder if the same is true for ...
>
> final public static function
>
> I've just done a quick scan of all my methods ...
>
> 5 abstract protected function
> 2 abstract public function
> 2 final protected function
> 11 final public function
> 1 final public static function
> 1 final static public function
> 2 private final function
> 12 private function
> 8 private static function
> 120 protected function
> 5 public final function
> 125 public function
> 11 public static function
> 3 static function
> 4 static private function
> 7 static protected function
> 16 static public function
>
> This is code that is 6 years old. As you can see I'm completely inconsistent.
>
> If there was some evidence that one order is preferable to another -
> pretty much ANY metric would do - then I'd probably adopt it.
>
> But I don't know if it makes ANY difference.
>
> OOI. I did the same analysis for Zend Framework (not the most recent,
> but a good a representative analysis as any I suppose).
>
> 1 abstract function
> 40 abstract protected function
> 153 abstract public function
> 1 final private function
> 1 final protected function
> 9 final public function
> 2 final public static function
> 150 private function
> 37 private static function
> 1 protected abstract function
> 1507 protected function
> 63 protected static function
> 5 public abstract function
> 2 public final function
> 11956 public function
> 701 public static function
> 1 static function
> 1 static private function
> 10 static protected function
> 60 static public function
>
> So, as mixed up as my own.
But it is good to know that at least the attributes are commutative. I was
never sure about that.
Bob McConnell
--- End Message ---
--- Begin Message ---
On Mon, Jan 31, 2011 at 3:51 AM, Richard Quadling <[email protected]>wrote:
> I've just done a quick scan of all my methods ...
>
I just did the same scan on my code, and the clear majority was
private abstract final function
YMMV
David
--- End Message ---
--- Begin Message ---
I suppose it comes down to preference of the programmer, since there is no
standardized rule for it, people adapt it as they find it convenient at the
time.
On Mon, Jan 31, 2011 at 1:52 PM, David Harkness
<[email protected]>wrote:
> On Mon, Jan 31, 2011 at 3:51 AM, Richard Quadling <[email protected]
> >wrote:
>
> > I've just done a quick scan of all my methods ...
> >
>
> I just did the same scan on my code, and the clear majority was
>
> private abstract final function
>
> YMMV
>
> David
>
--
Mujtaba
--- End Message ---
--- Begin Message ---
I've got an application that I'm fixing up and I'd like to run it through a
code formatter. Is there something like Perl Tidy for PHP? If so, what are you
experiences with it. No prob running it on the command line. It'd be great if
it followed the PEAR coding standards.
Thx
--- End Message ---
--- Begin Message ---
On Mon, 31 Jan 2011 13:27:42 -0700, Hansen, Mike wrote:
> I've got an application that I'm fixing up and I'd like to run it
> through a code formatter.
> Is there something like Perl Tidy for PHP?
Something _like_ ??!!! http://www.google.com/search?q=tidy+php
--- End Message ---
--- Begin Message ---
> -----Original Message-----
> From: Jonesy [mailto:[email protected]]
> Sent: Monday, January 31, 2011 2:25 PM
> To: [email protected]
> Subject: [PHP] Re: Code formatter
>
> On Mon, 31 Jan 2011 13:27:42 -0700, Hansen, Mike wrote:
>
> > I've got an application that I'm fixing up and I'd like to run it
> > through a code formatter.
>
> > Is there something like Perl Tidy for PHP?
>
> Something _like_ ??!!! http://www.google.com/search?q=tidy+php
>
Unfortunately most of those are trying tidy up the HTML not the PHP code. Also,
I was curious about those on this list and their experiences with any
formatters they have used.
Mike
--- End Message ---
--- Begin Message ---
On Mon, Jan 31, 2011 at 8:27 PM, Hansen, Mike <[email protected]> wrote:
> I've got an application that I'm fixing up and I'd like to run it through a
> code formatter. Is there something like Perl Tidy for PHP? If so, what are
> you experiences with it. No prob running it on the command line. It'd be
> great if it followed the PEAR coding standards.
>
>
Have you found http://pear.php.net/package/PHP_Beautifier yet?
;)<http://www.php.net/unsub.php>
Ken
--
http://blogs.linux.ie/kenguest/
--- End Message ---
--- Begin Message ---
Hello,
I would like to annouce that the latest stable version of Vermis has
just been released.
It is based on Zend Framework and some of You might find it useful :)
Vermis-1.0-r130-20110130
demo: http://vermis.ognisco.com/demo
home page: http://vermis.ognisco.com
What is Vermis?
Vermis is an Open Source issue tracker and project management tool for
software developers and project managers that has been created for
improving quality of code, efficiency and speed of development. Designed
as a standard web application written in PHP, it can be used on almost
any platform and hosting service, including Windows, Linux and more.
What's new:
- The 'web' directory has been removed
- No longer a need for a vhost
- Support for custom themes
- Support for i18n
- Localizations
- Many bugfixes
Feel free to download test and use Vermis, more on the project's home page.
Any feedback highly appreciated! :)
Thanks
--- End Message ---
--- Begin Message ---
Hello All,
I am new to the list so please be gentle :)
I am working on a PHP framework and have run up against a functionality
hurdle which I keep falling at. Basically, I have three mechanisms which all
function in a similar way and require this functionality: templating, event
handling and "action handling". Within the core code of the application, as
is common with many applications with plugin architecture, I pass a number
of parameters to functions which have hooked into a particular "event". Part
of the mechanism is that parameters can be passed by reference to allow for
the listeners to make modifications.
$username="bob";$account_type="ISV";$password="fishbum";
register_action_listener('process_user', function($username, $account_type,
$password){$username.="." . $account_type;} // Or whatever
call_action('process_user', &$username, &$account_type, &$password);
//Result: $username == "bob.ISV"
Now, what I am trying to do is establish a method to prevent the "hook"
functions from making changes by reference without reference explicitly
being passed to them by the calling code.
I have thought of a method which simply makes a copy of all the parameters
for each listener within call_action(), however what I would really love is
a function which returns whether or not the supplied variable is available
in multiple scopes or is in the original scope which it was initialized in.
Does anyone know of a way to achieve this?
Regards,
Brad
--- End Message ---
