this post was submitted on
9 points (80% like it)
12 up votes 3 down votes
shortlink:
to anything interesting: news article, blog entry, video, picture...

8
9

Best practice for making a third party class match naming standards? (self.PHP)

submitted ago by jonatcer

I'm working on a framework for my own personal projects and I need to use a few (LGPL) third party libraries, such as swiftmailer. The problem is I want to adhere to strict naming standards, such as $className->MethodName($variableName);. Obviously not all libraries follow the same standards, so what would be the best way for doing this?

Right now my best guess is something like

include('library);
class className extends library {
    public function AliasName() {
        call_user_func_array('parent::alias_method', func_get_args());
    }
}

Is there a better way to do this? This seems like it would be slow.

all 21 comments
sorted by:
best
hot
new
controversial
top
old

[–]dedpez 23 points24 points ago

Another option is not to have third party classes match your strict naming standards. That way you won't have to go through the rigmarole of wrapping and changing code.

[–]SkepticalMartian 3 points4 points ago

It's amazing how many people don't get the obvious answers, and try to over-engineer themselves a solution.

[–]shawncplus 2 points3 points ago

Absolutely, short answer: don't. It's 3rd party, keep it that way.

[–]greut 8 points9 points ago*

Keep your naming standards for your code and use 3rd party libraries as is. PHP is about this kind of incoherence, just take a look at PHP itself:

Writing adapters for every libraries you are including will be a real pain in the backside to maintain.

If you have nothing better to do of your time than nite-picking with naming standards, then do it ;-)

[–]jonatcer[S] 1 point2 points ago

Yeah, and I hate PHP for it :(. The problem with sticking to their naming standards, is I'm using a MVC-influenced design, so I'd have to add special exceptions for the third party stuff... Which doesn't sound like fun.

Unless I could just include(), then class properName extends ImproperlyNamedClass, and have it be empty.

[–]warmans 3 points4 points ago

I seriously wouldn't suggest doing this. If you just don't like using inconsistent class constructors you could just implement a factory for third party classes. It wouldn't resolve method names but they're not case sensitive anyway so if you wanted to really complicate matters you could just call them in in camel-case as per your example. Generally speaking MOST people prefer class names to begin with a capital letter and methods to start lower case so I wouldn't break this standard unless you have a really compelling reason.

[–]greut 5 points6 points ago

BTW try to forget about include and use a proper autoloader: PSR-0. Check those slides: http://www.slideshare.net/weaverryan/a-php-christmas-miracle-3-frameworks-1-app

[–]baileylo 0 points1 point ago

Thanks for that slideshare - probably one of the better slide shares I've read in awhile.

[–]dedpez 1 point2 points ago

Naming standards are simply for users to guess at a method name or mine meta, like identifying a private vs public method. If code is documented consistently then naming standards aren't necessary. I have more of a problem with code that is not documented than camelCase and underscores peppered in my code.

[–]McGlockenshire 3 points4 points ago

Please be aware that your own internal coding standard is in opposition to multiple coding standards adopted by the PHP community.

I'm not saying you need to change your code, but the fact that so many third party libraries do it differently (and generally consistently) should be a hint.

A non-trivial chunk of the rest of the world uses $lower_underscore variables, lowerCamelCase methods and UpperCamelCase classes.

[–]jonatcer[S] 0 points1 point ago

Yeah, my example wasn't the greatest and not really what I'm using. Just typed up the post on my laptop. As for the standards the rest of PHP users use, mind sharing the exact specifics, or a link?

And yeah, some of the libraries I want to use have underscores and the like. Ugh.

[–]McGlockenshire 0 points1 point ago

The PEAR coding standard and related ones like the one for Zend Framework might be good examples.

For something different, there's Symfony's standard.

[–]baconpiex 4 points5 points ago

You are making a serious architectural mistake by doing so.

[–]sarcasm_or_empathy 0 points1 point ago

While there are a handful of times it's necessary to use functions like call_user_func_array() (and it can definitely make implementation easier), be aware that anytime you indirect to identifiers through strings, you do so at the risk of disabling static analysis of your code e.g. for automated refactoring, code coverage analysis, unused functions analysis, etc. Unlike properties exposed by magic methods (which can be PHPdoc'ed with @property), there's no standard way (that I'm aware of) to teach a code analyzer how to recognize callbacks, or indirectly referenced variables e.g. ${$variableName}.

In situations like you describe, I tend to stick the rogue libraries at the end of my include path, wrap them lightly (if at all), and just "leave them be". Doing any more to third-party code is signing up for eternal vigilance/maintenance when that third-party library gets updated.

[–]jonatcer[S] 1 point2 points ago

Mind sharing what you do exactly? Wrapping wise.

I've been thinking about how I want to handle it after hearing everyone's opinions here, and I'm starting to think just going the CodeIgniter library route may be best. As in, have the base model have the ability to load libraries and just keep everything the same. Consider libraries as their own code entirely.

[–]sarcasm_or_empathy 0 points1 point ago

I think about what it is I am wrapping, and try to generalize it to the abstract.

For example, if I'm trying to wrap some grungy payment processing client library, chances are there are just a handful of operations I'm really going to need e.g. authorize, capture, credit, void, etc.

I then create an interface which prescribes what a payment provider fundamentally needs to be able to "do". This interface uses payment processing domain method names (authorize(), capture(), etc.) but the parameters are from my company's domain (for example, the interfaces which describe accounts, transaction identifiers, money, etc.).

Then I create the concrete class which basically maps from my company's domain to the payment processor's domain. In doing this there is usually occasion to create data transfer objects for encapsulating messages to and from the payment provider. Out of these DTOs I try to abstract yet more interfaces or abstract classes, although it's often hard to tell what these should look like until you've dealt with a few different service providers.

I'm not familiar with CodeIgniter libraries but to the extent it isolates third-party code and makes it look like "regular" code in your system, it sounds like a reasonable approach.

[–]warmans 2 points3 points ago

Maybe look at the Proxy Pattern for some ideas on how to implement this sort of thing. Though if all the libraries you want to include use something like the PEAR standard it might be easier to just switch to that than try and proxy everything into your own standard. Even if they're not all the same you might find than 90% use PEAR and 10% use something else.

The other option would be to just run something like CodeSniffer and go though it's report and fix everything in the classes. though this would make updating the changed classes more difficult.

[–]mageganker 0 points1 point ago

$asshole_coding_practices

[–]jonatcer[S] 0 points1 point ago

$asshole_coding_practices

How so? I'd be doing this with LGPL only, including references to them in any documentation, and reference them whenever else I can.

[–]mageganker 1 point2 points ago

Because instead of spending your time creating incredible things, you waste it on debating whether you to call your variable $penis or $Penis.

If anybody is looking over your code later they're going to have to look it up regardless so who the fuck cares.

[–]exochicken 0 points1 point ago

Usually it's the reverse that happens:

ClassName->methodName($variableName);

but you're free to do whatever you want. The only language that I know that enforces it is golang where public methods begin with an upper-case letter and private methods with a lower-case letter.

Use of this site constitutes acceptance of our User Agreement and Privacy Policy. © 2012 reddit inc. All rights reserved.

REDDIT and the ALIEN Logo are registered trademarks of reddit inc.

π Rendered by PID 27981 on app-61 running 86c9e1d.