Saber se função está sendo usada como parâmetro

Do mesmo modo que um resource, possui uma função para isso:

is_callable()

Entretanto, nunca utilizei. Essa denotação de type hint de callback ser um callable, é para o PHP 5.4

http://www.php.net/manual/en/language.types.callable.php

Li essas duas páginas e fiquei pensando aqui, mas acho que não é o que quero (ou não entendi).

O que quero que ocorra é isso:

• A função y faz determinada ação (retorna "olá")
• Caso a função y esteja sendo usada como parâmetro da x, sua ação será diferente (retorna "oi")

Entendeste? :P

Até mais.

Não entendi bem o que você quer, mas vamos aos exemplos. Bom, vamos as retificações. Você só pode passar como parâmetros closures. A função y não é uma closure, então ela nunca poderá ser passada como parâmetro.

Vamos a closure então:

$y = function () {}
function x($param) {
 if(is_callable($param)){
 echo 'é uma função';
 } else {
 echo 'não é uma função';
 }
}

Lembrando que closures são para versões do PHP >= 5.4

Você no máximo pode passar como parâmetro o nome(string) da função e então executar a função:

function y() {};
function x($param) {
 if(is_callable($param)){
 echo 'é uma função';
 call_user_func($param);
 } else {
 echo 'não é uma função';
 }
}
x('y');

Entretanto, não vi sentido algum no que você quer fazer. Poderia me explicar melhor?

É... também não é isso aí não.

Bom, vou explicar:

Estou fazendo uma classe mais ou menos como a Active Record, do CodeIgniter, porém de um jeito que acho melhor. Esse problema aí se refere aos métodos where($column, $operator, $value) e and($clause1, $clause2)/or($clause1, $clause2).

O and() e or() não fazem mais do que adicionar " AND " ou " OR ", respectivamente entre as condições ($clause1 e $clause2). Porém estou usando encadeamento de métodos nessa classe, então praticamente todos métodos retornam a instância ($this), e preciso que quando o método where() estiver sendo usado como parâmetro de and() ou or() ele retorne apenas o código do WHERE, e não a instância.

Parte do código da classe:

class DM {
private $sql; //Código SQL atual

	public function or($clause1, $clause2) {
 $this->sql = $this->sql.$clause1." OR ".$clause2;
 return $this;
	}

 public function where($column, $operator, $value) {
 $where = "WHERE ".$column.$operator.$value." ";
 /*
 ...
 */
 return $this;
	}
}

Suponhamos que eu queria usar assim:

$manager = new DM;
$manager->query(

 $manager->select("TABELA", "COLUNAX")->or(
 $manager->where("COLUNAY", "VALORY"), $manager->where("COLUNAZ", "VALORZ")
 )
)->fetch();

Não pode retornar a instância lá no método **where()**, e sim o conteúdo da variável** $where**, por isso preciso que **where()** mude seu comportamento (deixando de retornar** $this **para retornar **$where**) quando ele estiver sendo passado como parâmetro de** and() **ou** or()**.

Eu havia pensado em adicionar um quarto parâmetro booleano no método where() para ser definido quando for usar como parâmetro, mas fica ruim, feio...

Entendestes?

Até mais.

Alterar o comportamento de um objeto é utilizado em um padrão de projeto, o State. Mas no seu caso, você está apenas dando mais responsabilidades a um método que ele não deveria ter.

Uma SQL (sim, é no feminino mesmo, pois é UMA linguagem) não é nada mais que uma composição de elementos da linguagem (clausulas, instruções, expressões...). Nada, dentro da SQL, efetua duas ações distintas. Algumas coisas até podem ser utilizadas em lugares distintos, mas suas responsabilidades são sempre as mesmas.

No caso da cláusula WHERE, ela define condições para a consulta. Cada condição é uma expression, que pode definir igualdade, diferença, range, busca textual, entre outras. Um conjunto de instruções deve, também, ser separado por outras instruções, o nossos famosos operadores lógicos. Tirando algumas peculiaridades de SGBDs, cada elementos da linguagem, possui uma única função, uma única responsabilidade. De cabeça, não consigo me lembrar algo que faz duas coisas.

Como todas as linguagens de programação, SQL não foge a regra de ser uma linguagem interpretada. O padrão Query Object, baseado no padrão Interpreter e utilizado pelo Hibernate, prova o fato em abstrair a linguagem SQL da linguagem do programador. Query Object também pode ser conhecido como Criteria.

Sugiro a leitura deste post do, João Bastista Neto, onde é, como sempre, nos dada uma aula sobre padrões:

http://forum.imasters.com.br/topic/401441-organizar-codigo/page__p__1572696#entry1572696