[#ZF-1308] Coding standards compliance, including private method names

Zend Framework

Coding standards compliance, including private method names

Created: 23/Apr/07 03:37 PM Updated: 26/Feb/08 12:56 PM

Component/s:

Zend_Service_Audioscrobbler

Affects Version/s:

0.9.2

Fix Version/s:

1.0.4

Time Tracking:

Not Specified

Public Fields

Internal Project Management Fields

Tags:
Participants:	Darby Felton and Simone Carletti

Fix Version Priority:

Should Have

Description

« Hide

The private Zend_Service_Audioscrobbler::getInfo() method does not follow coding standards for private and protected method names:

Though function names may not contain the underscore character, class methods that are declared as protected or private must begin with a single underscore, as in the following example:

class Zend_Foo 
{ 
    protected function _fooBar() 
    { 
        // ... 
    } 
}

Other members of this component, such as $testing and $testing_response also should be modified to comply with coding standards.

I should also recommend considering whether private is the appropriate designation for such class members. Though sometimes appropriate to use private, it is generally the case that making class members protected allows for an appropriate public API while providing for extensibility through class inheritance.

All

Comments

Work Log

Change History

FishEye

Crucible

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Simone Carletti - 08/Jan/08 03:15 AM

I contacted Chris, I'm going to take in charge this fix.

@ Darby

Considering that those methods/variables were declared as protected, I assume it's safe to change their scope/name for the next ZF release (1.5). There shouldn't be any BC issue.

Do you agree?

[ Permlink | « Hide ]

Darby Felton - 08/Jan/08 08:19 AM

Well, I do not agree that there is no BC issue. Obviously people who have extended the class could be affected. However, because the likelihood of such extension for this component seems minimal, and because the BC impact deals only with naming (e.g., not behavioral changes to class logic), I do not see insurmountable problems arising with making the changes for 1.5. Thanks for looking at this, Simone!

[ Permlink | « Hide ]

Simone Carletti - 08/Jan/08 08:40 AM

> Obviously people who have extended the class could be affected.

Perhaps I confused PHP behavior with Java... but as far I remember (in PHP) child classes haven't access to parent private methods but only to protected or public ones.
But may be I'm wrong, I'm going to run more tests.

> I do not see insurmountable problems arising with making the changes for 1.5.

Great, I'm going to fix this ticket asap.

[ Permlink | « Hide ]

Darby Felton - 08/Jan/08 08:47 AM

Perhaps I confused PHP behavior with Java... but as far I remember (in PHP) child classes haven't access to parent private methods but only to protected or public ones. But may be I'm wrong, I'm going to run more tests.

Yes, of course, I meant that renaming protected methods could affect extending classes.

Thanks again!

[ Permlink | « Hide ]

Simone Carletti - 08/Jan/08 09:39 AM

fixed in r7364

[ Permlink | « Hide ]

Simone Carletti - 29/Jan/08 02:39 PM

Merged to branch/release-1.0 (r7688), target changed to mini release.