Slashdot Mirror

http://www.php.net/manual/en/s...
http://pecl.php.net/package/up...

I've never done my own garbage collection, and PHP just updated it in 5.3.

PHP works, it's fast as heck, and I can do anything you can do in python/perl just as well and way faster.

I don't know about python/perl but there are operations in PHP that need 200MB of memory which I could achieve in C with only 20KB of memory.

That's a 10,000x increase in memory consumption for PHP. If this has improved in version 5.5 I can't wait to give it a try.

And it's not just memory consumption, there are times when I run a xhprof on some slow PHP code and find out it's spending 90% of it's time allocating and/or freeing memory. If it used less memory, it would spend less time managing it.

PHP is a great language, but it's definitely not perfect. Memory and performance are "good enough" in most cases, but it's far from great.

Also, I have had to do my own manual garbage collection at times. There are no manual malloc/free API calls but I definitely do need to make use of unset() at times or otherwise refactor my code to reduce memory consumption.

A few years ago, PHP had several large frameworks (e.g. CakePHP, CodeIgniter, and so on). Each framework was an island and provided its own implementation of features commonly found in other frameworks.

More like frameworks deliberately exist to create islands with their own implementation of features commonly found in the language itself:

• this vs this
• this vs this
• this vs this

and on, and on, and on...

The headline should read, "Derps fall for new patchwork to solve self-inflicted fracturing problem, film at 11"

A few years ago, PHP had several large frameworks (e.g. CakePHP, CodeIgniter, and so on). Each framework was an island and provided its own implementation of features commonly found in other frameworks.

More like frameworks deliberately exist to create islands with their own implementation of features commonly found in the language itself:

• this vs this
• this vs this
• this vs this

and on, and on, and on...

The headline should read, "Derps fall for new patchwork to solve self-inflicted fracturing problem, film at 11"

A few years ago, PHP had several large frameworks (e.g. CakePHP, CodeIgniter, and so on). Each framework was an island and provided its own implementation of features commonly found in other frameworks.

More like frameworks deliberately exist to create islands with their own implementation of features commonly found in the language itself:

• this vs this
• this vs this
• this vs this

and on, and on, and on...

The headline should read, "Derps fall for new patchwork to solve self-inflicted fracturing problem, film at 11"

Wake up time. PHP actually has a pretty decent way to remove "garbage". First they make the compiler (and documentation) warn you about a feature being made obsolete in a future version, and then a few versions later they do remove the feature.

Here is an example (quote from the manual):

As of PHP 5.3.0, you will get a warning saying that "call-time pass-by-reference" is deprecated when you use & in foo(&$a);. And as of PHP 5.4.0, call-time pass-by-reference was removed, so using it will raise a fatal error.

Don't you mean "mysqli_real_escape_string?"

http://us3.php.net/mysql_real_...

I kinda liked PHP but this stuff started to annoy me. Not only are these methods database specific, but there are tons of deprecated functions in PHP. Sure it's usable - but it's very easy to use functions you're "just not supposed to." Though perhaps that's something they're trying to change as well?

Until I can get at least a warning on reads to undefined variables I will never use PHP for anything serious again.

Look into ini_set. Specifically 'error_reporting'.

register_globals hasn't been part of the default PHP runtime since 2002.

see: http://www.php.net/ChangeLog-4...

There are a lot of WTFs to PHP, something that hasn't been true since the first Bush administration isn't one of them.

You mean like PDO?

By sanitize, I mean, don't just write, "INSERT INTO table (col1, col2, col3, col4) VALUES ($unescapedValue, $hosed, $haxedLol, $bobbyTables)".

Which you can totally do in Ruby, Python, C#, NodeJS, etc.

I know mysql_real_escape_string is kind of a pain in the ass. Not to mention a huge WTF. Is the other one fake or something? Still, it's not perfect, but can you do Real Work in it? YES. It's not MUMPS for god's sake.

That's, er, function hashing - http://news.php.net/php.intern...

I've never done my own garbage collection, and PHP just updated it in 5.3.

PHP works, it's fast as heck, and I can do anything you can do in python/perl just as well and way faster. My host for my hobby site (Shameless Plug) gives me php and a mysql DB for $7 bucks a month, and that's probably more than I should be paying. If I want perl/python that goes up to $100/mo...

yeah - http://php.net/password_hash

It's now pretty easy to do password hashing correctly.

I can agree with that. PHP is a really "crufty" language. You can tell that it has "accreted," as opposed to was planned.

For example:

array_search($needle,$haystack)

vs.

strrchr($haystack,$needle )

(note the differences in the order of the parameters).

There are examples of this kind of craziness all over PHP. I spend a lot of time looking up functions, because I make boneheaded mistakes by doing things like putting the needle first, etc.

I can understand that there are more things than CMSes; but we just have to understand and accept that the days of hand-crafted HTML sites have gone the way of the dodo.

Modern, useful, commercial (as in what people pay for) Web development builds on platforms. No one gets paid (more than peanuts) to write standalone HTML Web sites (except for those "Beuatifil Web site for $300" spammers from Indonesia).

The type of CMS can vary, but you have two choices: Heavy-duty systems, based on Java or .NET, or PHP-based stuff.

There are a couple of Python or Ruby ones, but they are WAY down on the list.

Unless we will be training how to actually develop CMS sites (a HUGE curriculum; right there), we need to train folks how to build on top of them.

In these cases, creating usable, attractive and efficient "skins" is important. It's a badly-needed discipline. Geeks tend to be awful graphic designers. I think "magpie on LSD" best describes the taste of many hard-core geeks.

Usability is also essential for Web services these days; especially with mobile devices coming into such massive use. Usability is CRITICAL for mobile devices.

Things like Responsive Design are non-trivial topics that could easily take up a semester course.

There's a hell of a lot to teach before we get to server-level code.

I can agree with that. PHP is a really "crufty" language. You can tell that it has "accreted," as opposed to was planned.

For example:

array_search($needle,$haystack)

vs.

strrchr($haystack,$needle )

(note the differences in the order of the parameters).

There are examples of this kind of craziness all over PHP. I spend a lot of time looking up functions, because I make boneheaded mistakes by doing things like putting the needle first, etc.

I can understand that there are more things than CMSes; but we just have to understand and accept that the days of hand-crafted HTML sites have gone the way of the dodo.

Modern, useful, commercial (as in what people pay for) Web development builds on platforms. No one gets paid (more than peanuts) to write standalone HTML Web sites (except for those "Beuatifil Web site for $300" spammers from Indonesia).

The type of CMS can vary, but you have two choices: Heavy-duty systems, based on Java or .NET, or PHP-based stuff.

There are a couple of Python or Ruby ones, but they are WAY down on the list.

Unless we will be training how to actually develop CMS sites (a HUGE curriculum; right there), we need to train folks how to build on top of them.

In these cases, creating usable, attractive and efficient "skins" is important. It's a badly-needed discipline. Geeks tend to be awful graphic designers. I think "magpie on LSD" best describes the taste of many hard-core geeks.

Usability is also essential for Web services these days; especially with mobile devices coming into such massive use. Usability is CRITICAL for mobile devices.

Things like Responsive Design are non-trivial topics that could easily take up a semester course.

There's a hell of a lot to teach before we get to server-level code.

I thought Metaphone was a spell check algorithm designed to improve on Soundex

There is an RFC (at affected PHP.net site), which discusses the idea of named parameters for PHP 5.6. The proposal suggests that you would be able to use both named parameters and non-named parameters in the same function, but specifies that all functions using a mix must declare the order-dependent params before declaring any named params so that the interpreter knows how to handle the two.

Even PHP has database abstraction these days.

The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

http://php.net/manual/en/control-structures.goto.php
http://php.net/manual/en/function.extract.php
http://php.net/manual/en/function.mysql-real-escape-string.php
http://php.net/manual/en/function.eval.php
Also, have they added multithreading yet?

The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

http://php.net/manual/en/control-structures.goto.php
http://php.net/manual/en/function.extract.php
http://php.net/manual/en/function.mysql-real-escape-string.php
http://php.net/manual/en/function.eval.php
Also, have they added multithreading yet?

The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

http://php.net/manual/en/control-structures.goto.php
http://php.net/manual/en/function.extract.php
http://php.net/manual/en/function.mysql-real-escape-string.php
http://php.net/manual/en/function.eval.php
Also, have they added multithreading yet?

The problem is that there are some old functions in that language that should never have been added, and many of the developers of php apps don't know enough to avoid them. PHP can be a decent language if you have self control.

http://php.net/manual/en/control-structures.goto.php
http://php.net/manual/en/function.extract.php
http://php.net/manual/en/function.mysql-real-escape-string.php
http://php.net/manual/en/function.eval.php
Also, have they added multithreading yet?

Would you settle for PHP "type hints" (see http://php.net/manual/en/language.oop5.typehinting.php ) ? They add legible safeguards to function calls without introducing needless clutter to the language.

It's already here as of 5.4
http://docs.php.net/manual/en/language.types.array.php

PHP Array Short Syntax

There are answers to most of your gripes....except search function needle/haystack ordering. That one bugs me too, as I can never remember which function uses which order.

I stopped after i read about GOTO. Do you want raptors?

assert(""==false);
assert(0==false);
assert("0"==false);
assert(null==false);

When a form is submitted, there is no bare 0, there is only "0", so PHP treating "0" as if it where 0 in certain cases is certainly understandable. It may not be obvious or intuitive to you, but there is certainly a good reason for it.

See also: PHP type comparison tables

A comment on that page says:

just remember the following are always FALSE:
null, false, "", 0, "0", array()

Hardly complicated.

I participated in beta release testing for 5.5 and I'm frustrated that it still has old bugs that cause segfaults that continue to go ignored by the maintainers. I even supplied the patch and submitted a Github pull request, but the maintainers continue to ignore it.

It's no fun having to keep our own custom patchsets for PHP just to keep it running properly.

There hasn't been any excuse not to be using it for at least 5 years.

Except that bindParam/bindValue should have been stabbed in the spleen and left to bleed out slowly DECADES ago when Perl got hashes. Thank god PDO lets us use an associative array to execute statements but... lolz:

5.2.0 The keys from input_parameters must match the ones declared in the SQL. Before PHP 5.2.0 this was silently ignored.

How did that even WORK for two versions? Did they just assume that since :size was the first field in the query, "banana"=>"foo" must go in :size if it's the first key in the array?

Also, not accepting extra parameters doubles the work to generate dynamic queries. It's bad enough that

$sql="select * from tshirts"; $where=array();
if ($size) { $where[]="size='$size'"; }
if ($color) { $where[]="color='$color'"; }
if ($where) { $sql.=" where ".join(" and ",$where); }
$results=do($sql); // database specific

is easy, making it impossible to do

$sql="select * from tshirts"; $where=array();
if ($size) { $where[]="size=:size"; }
if ($color) { $where[]="color=:color"; }
if ($where) { $sql.=" where ".join(" and ",$where); }
$query=$dbh->prepare($sql);
$query->execute(array(":size"=>$size,":color"=>$color));

is just begging for someone to go back to the first way. Penalty points for having to deal with handling queries for NULL (not entirely PDO's fault, but the fact that I have to have to exclude the key from the array when I write IS NULL instead of =:key, is.)

It only gets worse from there (especially when you need filters for any arbitrary combination of a dozen+ fields). PDO can't reuse labels. No amount of karnaugh mapping will fix (A and B) or (not A and C) so you'll just have to know when you get to "not A" you're going to have to call it A2. In real use: name=:name or nickname=:name2 (though I recently discovered that :name in (name,nickname) is both valid and awesome in PostgreSQL). If you were going to suggest I could fix the above code with merely one more LOC (per filter) eg $params[":size"]=$size; .. ->execute($params), you can now hang your head in shame.

PDO is the CRUD framework of database connections, and should be treated as such when you get to something more complex than the usual crud. It could easily be improved, but that would require abandoning its deathgrip on how Perl DBI did it wrong way back when.

But it's 2013 now and in my opinion the language should have long been fixed.

You should probably read this, then

it WAS an image file you uploaded, right? It ended in .gif, right?

I want to become something other than one of these "absolute retards" you mentioned. If GD returns sane values for the image's width, height, and MIME type, what dangers should I still be aware of?

If you're going to troll, do it properly.

http://www.php.net

There is the difference that with a standard PHP setup, the whole framework must be parsed from the code

Look at APC - compile once and cache the code thereafter

establish database connections

Find out about Persistent connections

for each page view. With RoR, Django, etc., those things are only done once upon application startup and all pages are then served by the running application. Much faster.

I am not saying that PHP does not have its problems, but it is a good web platform. PHP's main problem is that there is a low barrier to entry, so people who do not have much clue can produce something ... that looks good, but is buggy with horrible security problems.

There is the difference that with a standard PHP setup, the whole framework must be parsed from the code

Look at APC - compile once and cache the code thereafter

establish database connections

Find out about Persistent connections

for each page view. With RoR, Django, etc., those things are only done once upon application startup and all pages are then served by the running application. Much faster.

I am not saying that PHP does not have its problems, but it is a good web platform. PHP's main problem is that there is a low barrier to entry, so people who do not have much clue can produce something ... that looks good, but is buggy with horrible security problems.

PHP is not getting a lot of love, especially here on Slashdot, and Drupal is one of the reasons to blame. Sure, PHP has its fair share of design flaws, but ever since version 5, it's a decent enough language to code in and can get a lot of done.

The problem is with Drupal, Wordpress, Joomla and other very popular CMSs and frameworks which are all a strange mix of procedural and oo code, and lack a proper distinction between model, views and controllers.

Its problems are certainly not the things that are often quoted, like mysql_real_escape_string (which just follows C api and is deprecated anyway), or inconsistent naming conventions. The problems are deeper - things like lack of threads comes to mind.

Still, the reason why I like PHP is that with a good framework (e.g. Zend Framework 2 is promising, but there is also CakePHP, FuelPHP, CodeIgniter, etc.) you can build a very solid application. Procedural PHP is actually a fantastic and very powerful template engine and otherwise you can write relatively clean and easy to read code in it if you structure the program correctly. It's very simple to deploy (especially compared to e.g. RoR) and has extensions for pretty much any database or graphics library or anything else a web developer may need.

In PHP docs with every item there comes the section for for "user contributed notes" which are sometimes pretty insightful (like there php strings intro or there implode string function ). Long time ago in a galaxy far away when I used to code in PHP those useful comments not only usually saved my day, but somehow compensated for the unorthogonality (well, an understatement) of the PHP standard library and the language itself. So - yes - I definitely prefer using worse language with better docs than the other way round (think Haskell vs PHP).

In PHP docs with every item there comes the section for for "user contributed notes" which are sometimes pretty insightful (like there php strings intro or there implode string function ). Long time ago in a galaxy far away when I used to code in PHP those useful comments not only usually saved my day, but somehow compensated for the unorthogonality (well, an understatement) of the PHP standard library and the language itself. So - yes - I definitely prefer using worse language with better docs than the other way round (think Haskell vs PHP).

MediaWiki is written in PHP. We should all include PHP in our kernels. PHP was chosen because of the easy of deployment, and popularity.

http://php.net/ - Introduction

1. First, yes, we agree that if you're root, you can do anything.

2. But, again, yes I was talking about admin on the website software, whatever it is. And that would be "guy with all permissions". Of course normally, you should set up and use lower privilege accounts, which contain the bare minimum of stuff you need to do your daily tasks. Only log in as admin once in a while.

3. However, let's say you are logged in as site admin. And you go to badsite.example.com, and they manage through some combination of bugs in your browser, CMS, and non-secure possibly wifi connection to execute commands as site admin.

4. Assuming #3, yes, an attacker should be able to execute arbitrary PHP.

a. First of all, he can probably upload a PHP file and navigate to that.

b. Or, run dynamic PHP with eval(). Example in Drupal. Like it says "While this is a powerful and flexible feature if used by a trusted user with PHP experience, it is a significant and dangerous security risk in the hands of a malicious user." But, it's enabled on many sites anyway for the flexibility it offers. ("You go to war with the PHP site you have, not the one you want.")

My recommendation: log in with the least privilege necessary. And turn dynamic PHP in your CMS.

Note: You can turn off the eval() function in php.ini with disable_functions. However, many PHP CMSs and frameworks make use of it for some of their dynamic magic/polymorphism/etc.

Surely you meant to write "mysql_real_escape_string"?

(I'm not asking if you meant to write "PDO prepared statements" - but you really should have, if you insist on working with madness that is PHP)

It's simple. The function takes a float argument. If you pass it a string, the string will be cast to a float before the function performs any actual analysis on it.

As you can see from the PHP manual, string conversion to number emulates the behavior of the Unix strtod(3) function; according to the man page for strtod(3), "If no conversion is performed, zero is returned".

So if an argument is passed which can't be converted to a number (e.g. empty string), the argument is converted to zero.

You can make PHP scream every mistake to the output buffer with the following.

Within code if you can't change php.ini
ini_set('error_reporting', E_STRICT | E_ALL); // or error_reporting( E_STRICT | E_ALL );
ini_set('display_errors', 1);

Or within php.ini
http://us.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
http://us.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

You can make PHP scream every mistake to the output buffer with the following.

Within code if you can't change php.ini
ini_set('error_reporting', E_STRICT | E_ALL); // or error_reporting( E_STRICT | E_ALL );
ini_set('display_errors', 1);

Or within php.ini
http://us.php.net/manual/en/errorfunc.configuration.php#ini.error-reporting
http://us.php.net/manual/en/errorfunc.configuration.php#ini.display-errors

maybe you should read it again

http://php.net/manual/en/function.number-format.php

it says
Return Values

A formatted version of number.

..and I'm going to ignore you and do what I wanted to do anyway. If my current tool doesn't allow it, I'll switch to one that does.

But insults aside, I think the way in which you said "you shouldn't be doing that" without even bothering to explain why, is part of the problem. You're basically saying that you know better than me, so much so that you shouldn't even have to persuade me, that I should just accept your superior knowledge. That approach never works, and it's pretty insulting to be on the receiving end of it.

If you want to advocate a better way or explain why "continue 2" is bad, you can certainly do that, but just trying to force your position upon everyone isn't the answer. If you try, someone else (in this case, php) will come along and give the people what they want...

I'm sorry that you felt insulted by my comments; that was not my intent. I suppose that, by repeating the criticism, I was acting along the lines of "If one man calls you an ass, ignore him; if three men call you an ass, get thyself a saddle". Or, I would say, maybe you should check if you've been fed too much hay. I have better things to do than to wait around for chances to insult fools; there are other ways of wasting time that I enjoy much more. The fact that I am willing to risk insulting you means that I think you are not a fool.

Second, I am by no means a Guru, but I got into the programming game very early, and I took the advice of people who got into it even earlier, and who are far better programmers than I will ever be. Truly, I am not fit to even polish their sandals. Sometimes, the advice was couched in terms that were not very flattering ("Hey, that's dumb. Do it this way.) Because I respected the experience of these elders, I would try out their way, and try to understand why it might be better than mine. Sometimes it wasn't. Of course you don't know me, and have no reason to give me the slightest degree of respect. However, the fact that you are hearing so much criticism of PHP ought to make you at least look at this criticism closely. There's plenty of stuff out on the Web about this issue, so reasearch might be indicated.

I don't even know PHP, and have no long-standing animosity to it. My web programming has been done in Perl CGI. I don't think that Perl is the One True Way. Python is not a bad choice either; I don't like Python (for what seem to others like arbitrary reasons), but I respect the language. I'm tired, it's late, etc. but I did a quick search for this break 2 statement you were talking about. I found the following code snippet at this site (I'm sorry about the munged indents; I don't recall how format code in HTML right now):

$i = 0;
while (++$i) {
switch ($i) {
case 5:
echo "At 5\n";
break 1; /* Exit only the switch. */
case 10:
echo "At 10; quitting
\n";
break 2; /* Exit the switch and the while. */
default:
break;
}
}

OK, this grates on me, but it's not hard to understand what it does. It doesn't seem obviously evil. But further down that same page, there is the following comment:

If the numerical argument is higher than the number of things which can be broken out of, it seems to me like the execution of the entire program is stopped. My program had 8 nested loops. Didn't bother counting them, but wrote: break 10. - Result: Code following the loops was not processed.

Say what??? "break 2 seemed innocuous, if kludgy; but I didn't understand that you could use just any index after the break. And apparently the PHP interpreter or compiler or whatever does no checking on the index. So you could have break 10 or maybe 250. Maybe this would work as you intended when you first wrote it, but can you really not see h

Yes throwing an error would be better than an inconsistent or, for some developers at least judging by the comments, an illogical result.

If you pass a string to number_format(), php generates a warning.

People whine about php being inconsistent, then when they make changes to make it more consistent, people whine.

They're damned if they do, and damned if they don't.

The fine individual who reported the 'bug':

• Has warnings turned off in his php config (OK for production, but stupid for development)
• Jumps two major versions of php without reading the documentation (this change is the first item on the upgrade notes for php 5.3)
• Is passing around strings and expecting them to behave like numbers in an application for tax and retirement planning.
• And surely the biggest WTF of the lot: He thinks that redirecting calls to number_format to a wrapper function will be hard to get through his 'change-request-release environment', but running and maintaining a private fork of php will be no problem

But it would appear the PHP devs don't think like that and instead like to preach that their arbitrary way of doing things is better than some other arbitrary way of doing things.

There's enough to criticise about php without attacking a straw man.

The documentation clearly states it takes a float, if you pass in a string (empty or not) you are relying on how that string is treated by PHP.

Yes, but the way it is treated seems to violate the way the documentation says it will be treated. This section of the manual states that strings will automatically convert to floats where the conversion is required by context. This section states that when a string that does not begin with a digit is converted to a numeric type, the result is 0.

Should an empty string be formatted as 0? I could imagine a situation where an empty string is returned by some other method because a value was not found in a DB, not because the value was 0. In that case formatting as 0 would be wrong. Lack of knowing a value doesn't make it 0, it makes it an unknown.

I completely agree, yet this is not how PHP is documented to work. Now, I consider the specified automatic conversion between strings and numbers to be a design flaw of the language, but as long as it is documented that empty strings are autoconverted to zero when context requires it, this should be what actually happens.

The documentation clearly states it takes a float, if you pass in a string (empty or not) you are relying on how that string is treated by PHP.

Yes, but the way it is treated seems to violate the way the documentation says it will be treated. This section of the manual states that strings will automatically convert to floats where the conversion is required by context. This section states that when a string that does not begin with a digit is converted to a numeric type, the result is 0.

Should an empty string be formatted as 0? I could imagine a situation where an empty string is returned by some other method because a value was not found in a DB, not because the value was 0. In that case formatting as 0 would be wrong. Lack of knowing a value doesn't make it 0, it makes it an unknown.

I completely agree, yet this is not how PHP is documented to work. Now, I consider the specified automatic conversion between strings and numbers to be a design flaw of the language, but as long as it is documented that empty strings are autoconverted to zero when context requires it, this should be what actually happens.

Silently failing is one of PHP's most common and egregious sins.

It doesn't silently fail. It generates a warning:

Warning: number_format() expects parameter 1 to be double, string given in /foo/bar/baz.php on line X

I'd rather it fail and fail loudly, so bugs like this can get fixed during development.

Which is why you don't disable warnings.

Maybe you want php to treat warnings as errors? No problem:

set_error_handler().

Why the hell would you expect the strings to be converted to some number though, when both operands are strings?

Because that's the documented behavior

If you compare a number with a string or the comparison involves numerical strings, then each string is converted to a number and the comparison performed numerically. These rules also apply to the switch statement. The type conversion does not take place when the comparison is === or !== as this involves comparing the type as well as the value.

Sorry, I don't understand what the problem is here? It's like complaining that the ^ operator in C is used for XOR when it's used for exponents in other languages or that = does assignment instead of a comparison in one language when it does both in other languages depending on context.

If you don't want a straight string comparison instead, you need to use a different operator (===). The complaint is equivalent to "I don't like this operator, I want to use the other one!" with the justification being "I don't understand how it comes up with 1000 from that crazy 1e3"

That's why I don't think the article is very good. it's not well thought out, virtually none of his complaints are supported/justified and when they are (he tries to justify his complaint), they don't show any real problem with the language other than "I don't like it" and sometimes "I don't understand it". Using the same standard he does, you could write a rant of similar-length about nearly every programming language.

To someone who isn't convinced, it's just not convincing. I would really recommend you find a better article that criticizes PHP. I can try to find one for you if you'd like.