Fill variable in exported file

Question: I am trying to export a file with email information and a variable of 'name' that will be replaced when importing it to another javascript file.
const emailTemplate = {
    subject: 'test',
    body_html: `

    <title>
    hey guys
    </title>

    Hey ${name}

    `
}

module.exports = {
    emailTemplate
}

However, I am not sure how I can fill the name variable when importing it somewhere else, and haven't been really able to look it up. Any ideas on what I could do in this case? Thanks!
This is how I import it in the other file.
const emailTemplate = require('./email/template')

Answer: You can export a function to output the html instead.
function getBodyHtml(name) {
    // your desired content
    return `

<title>
hey guys
</title>

Hey ${name}
`
}

const emailTemplate = {
    subject: 'test',
    getBodyHtml,
}

module.exports = {
    emailTemplate,
};

Then, call the function in another file.
// anotherFile.js
const emailTemplate = require('./email/template');

// call the function with the `name` variable in order to get the template
const myTemplate = emailTemplate.getBodyHtml('insert name here');

Comment: Thanks a lot! This did the trick, didn't think of that.

Fill variable in exported file


Halfspace Theorem in Differential Geometry

Question: I'm sutdying the Classical Halfspace Theorem, it says that :"There is no non-planar, complete, minimal
surface properly immersed in a halfspace of $\mathbb{R}^3$". But in this theorem, I don't know the definition of "complete". By the way, I would like to understand what does Theorem mean via some simple examples.
Comment: the more important part of the hypotheses is the word proper. https://math.jhu.edu/~js/Math748/hoffman-meeks.halfspace.pdf The examples without that hypothesis are not so easy.
Answer: For a Riemannian manifold without boundary $(M,g)$, completeness means one of the following equivalent conditions:

all (unitary parametrized) geodesics are defined on $\mathbb{R}$
the metric space $(M,d_g)$ is complete (all Cauchy sequences converge)
the compact subsets are the closed and bounded subsets

This is called the Hopf-Rinow theorem. Here, complete is to be understood as "every surface endowed with the induced Riemannian metric that is complete".
The half space theorem says that if a surface in $\mathbb{R}^3$ is non planar (thus, "curved"), complete (thus, geodesics do not end somewhere: there is no "missing point" or "boundary"), properly immersed (thus, the surface "extends to infinity"), and if it is minimal, then it goes "in every direction": there is no half-space in which you can enclose the surface. It has to go out of it at some time. Equivalently, it intersects every affine hyperplane.
Comment: For instance, if I replace the surface in definition by *entire graph* X(u,v) in three-dimensional space. Can we prove that the graph must be planes? Or something?


Question about integration of functions

Question: LEt $f$ be a measurable function. Define $\int\limits_E f dm = \sup Y(E,f)$ where $Y(E,f) = \{ \int\limits_E \phi dm : 0 \leq \phi \leq f \}$ and $\phi$ is simple function.
and $E$ is a lebesgue measurable set. I want to show that if $B \subseteq A$, $A$ and $B$ both lebesgue measurable, and $f$ measurable function then
$$ \int\limits_B f dm \leq \int\limits_A f dm $$
My try: Pick $b \in Y(B, f) \implies b = \int\limits_B \phi $ for some simple $\phi \leq f$. Since $\phi$ is simple,  can put $\phi = \sum c_i 1_{C_i} $.
Therefore, by definition of integral of simple functions, we have
$$ \int\limits_B \phi dm = \sum c_i m( C_i \cap B) \leq_{ monotonocity} \sum c_i m(C_i \cap A) = \int\limits_A \phi dm $$
Hence, $ \int\limits_A \phi dm  $ is an upper bound for $Y(B, f)$ So we have
$$ \sup Y(B,f) = \int\limits_B f dm \leq \int\limits_A \phi dm  $$
Im stuck in this part, can we conclude from here the conclusion of the problem? Can someone help me? thanks a lot for your time.
Comment: I presume you meant $B \subset A$?
Comment: .. and then $$\int_A \phi dm \leq \sup Y(A,f)$$
Comment: I feel so stupid for asking this
Answer: Suppose $a \le b$, then $Y(A,a) \subset Y(A,b)$, from which it follows that $\int_A a \le \int_A b$.
Now suppose $B \subset A$. Then let $a=f\cdot 1_B, b=f$. Then $a \le b$, and so $\int_A f\cdot 1_B \le \int_A f$. Since $\int_A f\cdot 1_B = \int_B f$ we have the desired result.
Comment: I cannot vote up this answer because I have exhausted my voting previleges for today. I will when I am able to vote again in couple of hours. Thank you.
Comment: No problem at all. Hopefully it helped.

Question about integration of functions


gcsfuse in Google App Engine flexible custom runtime

Question: I'm trying to use gcsfuse to mount GCS buckets in a docker container deployed in a GAE flexible custom runtime instance. This is part of the Dockerfile:
FROM gcr.io/google-appengine/python

RUN apt-get -y update
RUN apt-get -y install lsb-release
RUN echo "deb http://packages.cloud.google.com/apt gcsfuse-$(lsb_release -cs) main" | tee /etc/apt/sources.list.d/gcsfuse.list
RUN curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
RUN apt-get -y update
RUN apt-get -y install fuse gcsfuse

Then from the docker container I get an error when I run:
# gcsfuse --key-file=gcs_credentials.json bucket_name /tmp/mount_path
Using mount point: /tmp/mount_path
Opening GCS connection...
Opening bucket...
Mounting file system...
daemonize.Run: readFromProcess: sub-process: mountWithArgs: mountWithConn: Mount: mount: running fusermount: exit status 1
stderr:
fusermount: fuse device not found, try 'modprobe fuse' first

Then as suggested by the error message I run:
# modprobe fuse
bash: modprobe: command not found

I've seen in some other questions that I should run the docker container in privileged mode but I can't find how to do that with the container running in a GAE instance. Is there any other way?
Comment: I'm pretty sure that it belongs here. Check this https://serverfault.com/help/on-topic
Comment: Please ask this question at Stack Overflow since it is related to that forum of discussion.
Comment: Possible duplicate & solution https://stackoverflow.com/questions/56254714/problem-running-gcsfuse-on-google-app-engine
Answer: The problem is security context and privileges:
In Kuberentes:
securityContext:
  capabilities:
    add:
    - SYS_ADMIN
  privileged: true

In Docker you can try this question


Vantagens de usar PHP Orientado a Objetos? Onde usar?

Question: Ultimamente fiz uma mini mídia social e praticamente não utilizei a orientação a objetos, com exceção á uma classe que fiz para CRUD com PDO e bibliotecas prontas do GitHub.
Esse conceito seria aplicado mais para a construção de bibliotecas e APIs? Vi alguns padrões de projetos, mas não encaixei nenhum diretamente na construção de um sistema web.
Qual o real uso da OO em PHP? Algum exemplo de como aplicar a OO em um website?
Comment: Relacionada: [PHP mistura códigos de orientação a objetos e linguagem procedural?](http://pt.stackoverflow.com/questions/104340/php-mistura-c%c3%b3digos-de-orienta%c3%a7%c3%a3o-a-objetos-e-linguagem-procedural)
Answer: TL;DR
Orientação a Objetos (OO), independente da linguagem e do quanto ela adere à teoria, pode trazer os mesmos benefícios, sendo os principais relacionados à organização do código, facilidade de manutenção e capacidade de extensão das funcionalidade.
Você está certo em supor que OO é melhor para bibliotecas e APIs, já que código feito para uso de terceiros precisa ter uma interface bem definida, extensibilidade e encapsulamento, enquanto flexibilidade demais gera dores de cabeça para lidar com a evolução do código.
Entretanto, este paradigma, por si só, não resolve qualquer um dos problemas e, se mau utilizado, pode causar tanto ou mais danos do que ajudar.
Você não precisa de OO
Isso mesmo que você leu. Dá pra fazer tudo que se faz com objetos usando apenas programação procedural.
Uma boa linguagem de programação precisa basicamente de 3 componentes:

Estruturas de dados básicos: vetores, mapas, classes, tipos simples, etc.
Estruturas de controle: if, for, etc.
Estruturas de organização do código: subrotinas, blocos, funções, métodos, etc.

Agora, pense no que são classes, por exemplo. Tratam-se de uma composição de trechos de código organizados (métodos), os quais contém lógica de controle, e um conjunto de dados ou atributos (estado do objeto) que chamamos em PHP de $this.
Bem, você pode obter o mesmo resultado usando um conjunto de funções e uma estrutura de dados compartilhada entre elas. Quem sabe programar um pouco em C, por exemplo, sabe muito bem disso.
Exemplo procedural:
$this = criar_estrutura();
fazer_algo($this);

Exemplo OO:
$objeto = new Classe();
$objeto->fazer_algo();

Os dois códigos fazem a mesma coisa, entretanto no primeiro o estado é explícito e precisa ser passado em cada chamada ao conjunto de funções que são análogas aos métodos de uma classe.
Porém, como pretendo mostrar adiante, OO traz outros benefícios e não é à toa ou coincidência ou uma simples moda que a faz se tornar o paradigma mais usado no mundo.
Você pode encontrar bons materiais aqui no SO sobre vantagens de OO, sendo um exemplo esta pergunta.
O que distingue a Orientação a Objetos
Um grande diferencial da OO em relação aos outros paradigmas é que ele vai além no que diz respeito à abstração e encapsulamento dos dados.
Claro, nada é de graça. Com os benefícios vêm os efeitos colaterais, a saber, maior cerimônia, complexidade e restrições, além de impactos no gerenciamento de memória e no desempenho (não querendo dizer com isso que necessariamente um sistema vai ficar lento ou pesado só por usar OO).
Entretanto, o que se vê no geral é que o ganho pode ser bem maior que o preço pago por jogar dentro das regras dos objetos.
Quando você tem atributo privados encapsulando o estado de um objeto, pode ser "chato" ter que ficar acessando tudo por métodos. Em teoria (mas tem que ser muito teórico mesmo), um bom programador não precisa esconder suas estruturas de dados, apenas tomar o cuidado para não ser tentado a mexer no que não deve.
Porém, se olharmos projetos reais que envolvam produtos de verdade, constataremos que é ilusão achar que humanos simplesmente vão seguir corretamente todas as regras e boas práticas. Num projeto complexo, pode ser humanamente impossível estar a par do funcionamento de tudo.
Alguém pode argumentar que basta estudar a API do PHP para aprender a usar as funções, mas em projetos reais você também precisa aprender a API do sistema em particular e outros sistemas com os quais você faz integração, às vezes mais complexos e desorganizado que a própria linguagem (se é que é possível :P).
Dado esse cenário caótico, as restrições, padrões e regras impostos pela OO são muito bem-vindos em muitos casos.
Abstração e reuso
Como se faz reuso de código sem OO? Com funções. E como você faz para adicionar variações? Parâmetros.
O problema disso é que no decorrer do tempo você vai precisar alterar os parâmetros. Não é incomum em códigos PHP por aí encontrar funções com 10 parâmetros, alguns opcionais, outros desnecessários. E se você precisar remover uma parâmetro, vai ter que sair varrendo o código procurando pelas chamadas.
Uma alternativa a isso é receber vetores, mapas ou outras estruturas genéricas como parâmetros. Isso pode funcionar bem até certo ponto.
Ao usar objetos, você pode diferentes construtores e ter métodos para definir propriedades específicas que geralmente são opcionais.
Vamos agora a um cenário onde você tem uma rotina que processa uma entidade com vários atributos, sendo 2 deles obrigatórios e os demais opcionais.
Uma implementação OO poderia ser:
$cliente = new Cliente($cpf, $nome);
$cliente->setEndereco($end);
$email->enviar($cliente);

Uma versão procedural simplista seria:
enviar_email_cliente($cpf, $nome, null, null, $end); //demais parâmetros omitidos

Uma versão mais flexível:
enviar_email_cliente($cpf, $nome, array("endereco" => $end));

Considere ainda que este sistema é um grande ERP, composto por módulos desenvolvidos por diferentes equipes, e existem centenas de chamadas à rotina e em nenhuma delas os valores são estáticos como no exemplo.
Agora imagine que foi necessário remover o atributo endereco da entidade Cliente e mover para outra entidade, já que agora clientes podem ter vários endereços.
Agora vai a pergunta: o que acontece quando você efetua a mudança? Em qual dos casos a IDE ou o interpretador vai avisar você de que o atributo não existe mais?
Este é um trade-off entre flexibilidade e segurança. Muita flexibilidade, como é permitido e até incentivado em PHP, também é causa frequente erros difíceis de serem encontrados.
Encapsulamento
Posso imaginar que no seu sistema você tenha um punhado de variáveis, algumas globais, para trocar informações entre as funções. Se não tiver, parabéns, mas esta não é a regra.
O problema com variáveis compartilhadas é que você incorre no grande risco de que um trecho de código interfira com outros inadvertidamente.
Vamos a outro exemplo. Você quer monitorar o tempo de uma rotina muito demorada. Uma abordagem procedural ingênua usando uma variável global seria:
iniciar_timer();
foreach ($planetas as $planeta) {
    popular($planeta);
}
echo "Total: " . finalizar_timer();

Bem, obviamente isso funciona, mas não ajuda muito. A rotina demora muito e não se sabe em qual planeta estamos tendo mais dificuldades em popular. Queremos saber o tempo total, assim como o tempo individual.
Poderíamos melhorar da seguinte forma:
$inicio_geral = iniciar_timer();
foreach ($planetas as $planeta) {
    $inicio_parcial = iniciar_timer();
    popular($planeta);
    echo "Planeta $planeta: " . finalizar_timer($inicio_parcial);
    echo "Parcial: " . (time() - $inicio_geral);
}
echo "Total: " . finalizar_timer($inicio_geral);

Pronto, agora não termos mais o estado global e podemos reusar a rotina.
Porém, verificou-se que o processo está vazando muita memória e se quer investigar quando isso ocorre. Para isso, precisamos recuperar a quantidade de memória alocada antes de executar a rotina e a quantidade de memória após ela executar e adicionar essas informações a um arquivo de log.
Como podemos alterar as rotinas para fazer isso sem mexer no código? Tenha em mente que essas rotinas estão sendo usados por outras pessoas que contribuem para a colonização da galáxia.
Se não queremos variáveis globais, podemos mudar o retorno da rotina inicar_timer para retornar um array contendo tanto o tempo quanto a memória e assim recuperar ambos valores em finalizar_timer.
Entretanto, você potencialmente está quebrando a implementação de várias pessoas, já que agora o echo não vai imprimir o que você esperava. Tudo isso porque programadores espertos, sabendo que você retornava um timestamp, acessaram diretamente o valor.
Alguém pode argumentar que é possível corrigir isso de forma simples. Por exemplo:
$inicio_geral = iniciar_timer();
foreach ($planetas as $planeta) {
    $inicio_parcial = iniciar_timer();
    popular($planeta);
    imprimir_tempo("Planeta $planeta", $inicio_parcial);
    imprimir_tempo("Parcial, $inicio_geral);
}
imprimir_tempo("Total", $inicio_geral);

Excelente. Agora explique para para mundo porque mais uma vez foram implementadas mudanças incompatíveis com versões anteriores e agora todos terão que ficar usando uma versão antiga do seu código ou parar o que estão fazendo procurando por todos os usos das rotinas afetadas, ajustando e testando tudo novamente.
OO não resolve todos os problemas, mas neste exemplo (e em vários outros que vejo no dia a dia) um correto encapsulamento do estado poderia ter resolvido todo o problema de início. Por outro lado, a falta de encapsulamento, tende a causar este tipo de problema.
Nesse ponto, as restrições e burocracias da OO teriam permitido que todas as alterações fossem feitas sem interrupção e sem introduzir incompatibilidades:
$geral = new Timer();
foreach ($planetas as $planeta) {
    $parcial = iniciar_timer();
    popular($planeta);
    $parcial->logTime("Planeta $planeta");
    $geral->logTime(Parcial);
}
$geral->logTime("Total");

Resumindo: as restrições impostas pela OO aumentam o reuso porque limitam a forma como o código cliente pode interagir com os dados.
Em programação funcional, por outro lado, poderíamos ainda ter um método que faz a contagem automaticamente. Exemplo:
monitorar_execucao("Total", function() {
    foreach ($planetas as $planeta) {
        monitorar_execucao("Planeta $planeta", function() {
            popular($planeta);
        });
    }
});

No exemplo acima, os logs de início e fim são feitos automaticamente e podemos adicionar quaisquer mecanismos de monitoração desejados.
E se quisermos dar um pouco mais de flexibilidade, podemos ainda disponibilizar um objeto como parâmetro:
monitorar_execucao("Total", function($timer_global) {
    foreach ($planetas as $planeta) {
        monitorar_execucao("Planeta $planeta", function($timer_parcial) {
            popular($planeta);
            $timer_global->log("parcial");
        });
    }
});

Note como usamos programação funcional e OO em conjunto para obter uma API mais flexível, segura e consistente. Podemos mudar a implementação interna sem afetar quem usa a rotina.
Entidades
Provavelmente você deve ter algumas entidades que salva num banco de dados.
Sem orientação a objetos, não é incomum se usar um conjunto definido de variáveis ou mesmo um mapa ou array para armazenar tais estruturas de dados.
Por exemplo:
$carrinho = ["Pão", "Leite"];

A não ser que seu sistema seja muito trivial, você deve ter encontrado alguns problemas enquanto criava rotinas para recuperar, inserir ou alterar dados. Ora você esquece quais os atributos um mapa carrega, ora você precisa passar um monte de valores por parâmetro, etc. Adicionar campos pode virar um pesadelo mais para frente.
Agora com quantidade:
$carrinho = [
    ["desc" => "Pão", "quantidade" => 2],
    ["desc" => "Leite", "quantidade" => 1]
];

Agora com valor unitário
$carrinho = [
    ["desc" => "Pão", "quantidade" => 2, "valor" => .50],
    ["desc" => "Leite", "quantidade" => 1, "valor" => 2.0]
];

Excelente, você não precisa de mais nada para ter os eu carrinho de compras. Vamos calcular o total:
$total = 0;
foreach($carrinho as $item)
    $total += $item['valor'];

Se há vários locais da sua aplicação onde você precisa percorrer, adicionar, remover, pesquisar elementos e assim por diante, você tem basicamente duas opções. Uma é acessar tudo manualmente como no exemplo acima e, quando ocorrerem mudanças (tal como novos campos), você sai mudando em todos os lugares. Outra é criar várias funções para manipular a estrutura de dados, tais como adicionar_item($carrinho, $item) e consultar_item($carrinho, $descricao).
Repare como tudo isso soa exatamente como meu primeiro exemplo de OO vs. procedural. Podemos resolver tudo isso sem OO, mas convenhamos, estamos reinventando a roda e fazendo manualmente o que poderíamos delegar para o interpretador do PHP fazer de forma mais segura.
Indo mais longe, mas vamos imaginar que agora você tem carrinhos com muitos itens e frequentemente precisa percorrer todos os elementos para totalizar ou consultar os itens. Primeiro você pensa em mudar a estrutura para algo como:
$carrinho = [
    "total" => 2,
    "items" => [
        "Pão" => ["quantidade" => 2, "valor" => .50],
        "Leite" => ["quantidade" => 1, "valor" => 2.0]
    ]
];

Resolve o problema, mas vai quebrar todo o código atual mais uma vez, caso você não faça todos os acessos via funções próprias.
Mas claro que você não precisa de objetos. Basta que cada módulo procedural tenha escrito na documentação algo como "não acesse as estruturas de dados diretamente!" E a partir daí obviamente você pode confiar que todo mundo, incluindo você, nunca vai respeitar esse desejo e usar corretamente sua API. Boa sorte! :)
Mais uma vez:

A falta de encapsulamento é fonte comum de problemas.
É complicado manter a consistência tendo apenas um conjunto "solto" de rotinas.
Isso também dificulta que outras pessoas criem novas rotinas e criem novas funcionalidades em cima das suas, pois a não fica claro como elas podem ou não usar sua estrutura de dados, enquanto com classes isso seria mais óbvio.

Objetos que representam entidades complexas são muito seguramente manipuladas pelas várias rotinas do sistema com uma interface bem definida em uma classe.
Usando o exemplo de validação, um objeto bem encapsulado garante a consistência interna dos dados, o que não é tão simples com funções isoladas. É claro que você pode criar uma rotina de validação e chamar em cada função, mas não é tão eficiente em muitos casos impeditivo ter que analisar em cada rotina toda a estrutura recebida para determinar se o estado é válido. Isso leva muitas bibliotecas a não realizarem validação suficiente, resultando em dificuldades para identificar problemas quando valores inesperados aparecem.
O potencial do PHP em diferentes paradigmas
Você pode resolver uma gama de problemas usando somente um paradigma específico, mas quase sempre, para uma aplicação não trivial um só paradigma não é a melhor escolha ou suficiente.
Quando falamos em programação procedural, funcional e orientado a objetos, devemos pensar em como podemos usar todos os paradigmas em harmonia para uma melhor solução.
Orientação a objetos é importante e todas as principais linguagens têm algum nível de suporte a ela ou possuem variações para suportar o paradigma, tal como o C++.
Programação funcional é outro paradigma que todas as linguagens procuram aproveitar até certo ponto. Mesmo linguagens como o Java,  tradicionalmente nada amigável a este paradigma, abraçou-o veementemente em sua versão 8.
Já programação procedural é algo que, até certo ponto, inevitável. Ainda não estamos no estágio (e não estou certo de que chegaremos) onde tudo poderá ser resolvido por expressões funcionais. As boas e velhas estruturas de controle tais como if e for ainda vão existir dentro dos métodos e funções.
O interessante do PHP é que ele possui um suporte razoável para todos esses paradigmas, embora alguns sejam mais bem explorados do que os demais.
A linguagem é muito conhecida por ser de fácil aprendizado, onde alguém consegue ter algum código executando com sucesso no seu primeiro dia, senão na primeira hora.
Por causa disso, parte da comunidade encontra dificuldades com o uso de OO e mesmo programação funcional já que são conceitos que levam mais tempo para digerir, além do que o PHP tem uma herança procedural muito forte e praticamente todos os módulos possuem uma API procedural, às vezes suportando OO ao mesmo tempo ou misturando objetos com funções isoladas.
Vejo um movimento da comunidade PHP em direção ao uso de outros paradigmas, mas menos para programação funcional, o que é uma pena.
Enfim, seria bom ver os três paradigmas funcionando em conjunto permitindo soluções melhores em todas as áreas.
Exemplos onde Orientação a Objetos é ruim
Lugares onde em geral OO não é legal ou é usada apenas indiretamente incluem:

Templates, por exemplo, como os templates HTML do Wordpress onde você mistura lógica de controle com código HTML. Mesmo em outras linguagens isso vale. Embora objetos auxiliares (helpers) sejam usados, um template de texto é intrinsicamente procedural em sua natureza.
Funções sem estado (stateless) não armazenam nem compartilham variáveis, nem possuem pré-requisitos. Por exemplo, mesmo numa linguagem puramente OO, uma rotina para converter um inteiro em texto não precisa necessariamente estar em um objeto. O Java, por exemplo, usa método estáticos para esses casos.
Rotinas de alto desempenho funcionam melhor com estruturas de dados simples.

Padrões de Projetos
Vários projetos de código livre morrem por falta de manutenção devido à má estruturação, pois ninguém consegue ou tem coragem de mexer. Independente do paradigma utilizado, é importante aprender as melhores práticas.
Padrões de projetos não são exclusividade do paradigma de Programação OO, mas são soluções conhecidas para problemas específicos, além de uma linguagem comum para você não reinventar a roda e chamar de "cubo redondo".
Conhecer padrões de projeto podem lhe ensinar como outras pessoas resolveram certos tipos de problemas e, uma vez que você aprender alguns você perceberá uma coisa boa e outra ruim:

A boa é que você vai aprender outras formas de pensar sobre o problema que não teria feito sozinho e logo estará ajustando e compondo esses diferentes padrões em novas formas. Assim você usa a experiência dos outros para crescer mais rapidamente.
A ruim é que você começa a querer aplicar os padrões em tudo e acaba criando alguns monstrinhos até aprender (espero) a usar esses novos poderes com responsabilidade.

Considerações
Não só em bibliotecas ou frameworks, o uso de Orientação a Objetos é bem-vindo em qualquer funcionalidade do seu programa, principalmente quando você almeja reuso e comunicação entre diferentes partes do código ao mesmo tempo que que almeja certo encapsulamento para evitar problemas mais para frente.
Use o paradigma que for melhor para resolver cada problema, inclusive todos juntos. Mas para isso você vai precisar conhecer todos, além das boas e más práticas de cada um.
Comment: @Edilson Mais paciência. Primeiro você precisa entender que é de certa forma uma ironia. Você pode programar em binário também. Mas para não deixar você na espera, adiante que meu texto é uma defesa da POO. Basicamente meu argumento é que o fato de você não precisar de algo não significa que não seja melhor se você usar. Sinceramente, sugiro você não adicionar críticas assim sem ler até o final.
Comment: @Edilson já parou pra considerar que **talvez** as partes que você não concorda estejam corretas, e **talvez** sua visão esteja um pouco "engessada"? Não estou afirmando que é o caso, mas às vezes é legal entender que os autores de ambas as respostas não inventaram do dia pra noite o que estão escrevendo, e com certeza tem uma razão para cada ponto que expressaram. Se alguma parte não agradou eu acho legal vc se manifestar (eu fiz isso antes nessa mesma resposta, por motivo contrário do seu), mas acho muito legal ver e aproveitar tudo o que a resposta tem a acrescentar também.
Comment: "[...]criando alguns monstrinhos até aprender [...] " ... Me vi nisso! Fiz vários desses que eu não conseguia arrumar depois... rsrs Ótima resposta!
Comment: @Bacco Pergunta reformulada. Mas quanto mais cresce, mais complicada fica. Acho que fiz mais justiça aos outros paradigmas agora. :)
Comment: @Edilson nesse ponto eu concordo bastante com o utluiz. E vou falar algo que não tive a oportunidade de falar na minha resposta. OOP como foi implementado até agora em PHP é bem mal feito. Tá cheio de furos. E este é só um motivo a mais para evitar o seu uso nesta linguagem. Eu não sou um especialista mas estudo bastante o assunto porque gosto de linguagens e paradigmas. Eu não estou falando se eu gosto ou não, se acho útil ou não, falo de ser bom ou não. E acho que o utluiz fez o oposto do que você alega. A maioria das pessoas não entendem OOP, eu não sei se entendo. Vai gostar menos da minha
Comment: Espero não ter transmitido a ideia de estar aborrecido com a resposta e os comentários, mas questões são para ser esclarecidas. E obrigado a todos pela compreensão. +1
Comment: Obrigado pela a resposta deu para entender bastante sobre o assunto, sobre as globais acho que não usei não, no projeto em si só usei funções e classes em uma mini classe que criei para crud, as variáveis foram distintas por arquivos.. Uma dúvida que restou foi haver com a pergunta relacionada a essa, lá diz que não é indicável misturar OO com estruturada, logo não tenho a menor idéia de nao fazer essa mistura pois seria uma classe para cada página?
Comment: @utluiz eu acho que foi claro, tanto que já recebeu 4 votos e eu já recebi negativo. Eu já esperava, o que eu falo vai contra a maré e aí a pessoa negativa por causa disto. Ou é alguém que me persegue que aproveita a chance :). Mas a primeira é mais provável. A minha está tão fundamentada quanto a sua, ou seja, nenhuma está muito, não dá para fundamentar muito sem escrever uma tese. Se fosse isso o motivo do negativo, então as duas mereceriam. O motivo é a discordância. Então que ela exista, não entendo porque as pessoas não aprenderam que o voto não é para isto. A resposta está boa.
Comment: @Edilson Você devia ter continuado lendo. ;)
Comment: @Bacco, bigown, autor, eu li a resposta inteira, só para não ficar com _"ideias"_ como vocês mesmo disseram, e não disse que não concordo com nada, excepto claro àquele _heading_ ali a dizer explicitamente para não usar, talvez a vontade do autor fosse contraria ao que diz realmente o titulo, como acabou de citar, mas é um titulo que em parte perde o teor sugestivo. Eu não duvidei de única palavra escrita na resposta, foi apenas o título do ponto em questão, que deixa clara a mesma ideia presente noutras respostas relacionadas ao OOP aqui no SOpt, claro, embora não tenha sido propositado.
Answer: Introdução contextual ou TL; DR
Esta resposta é uma discordância democrática e saudável à resposta do utluiz. É necessário deixar claro isto porque algumas pessoas acham que diversidade de visão não é construtivo ou mesmo que é briga. Acho que aqui estamos fazendo de forma saudável e todos podem se beneficiar disto.
Melhor que uma pergunta que gera uma boa resposta é ter uma pergunta que gera várias boas respostas e que fazem as pessoas refletir e aprender mais, mesmo que discordem do que está escrito.
Para quem não tem paciência para ler tudo ou acha que já sabe o que precisa aprender sobre o assunto, o que eu digo é:

OOP é bom, mas não é panaceia.
Tudo o que o utluiz diz funciona bem em outros contextos, mas em PHP boa parte da vantagem do OOP se perde.
OOP traz problemas novos, sem resolver todos do procedural, portanto alguns problemas podem se beneficiar mais de OOP ou procedural, OOP não é adequado para qualquer coisa.
Afirmo que PHP costuma atender problemas mais adequados para procedural que OOP.
Muito do que é dito na outra resposta é sobre tipagem estática, e não OO.
A principal discordância é em usar exemplo de procedural ruim contra OOP bom, é injusto!

A resposta dele não está errada, tem qualidade, só quero dar uma outra visão. Em várias partes, concordo com o que está lá. Só acho que ela não está bem contextualizada para o PHP. A prática do PHP é um pouco diferente do que está descrito ali. A pergunta é sobre OOP em PHP, não em Java.
Algumas coisas desta resposta fazem mais sentido olhando a versão original da resposta dele.
Recomendo fortemente assistir um vídeo que mostra de forma clara como OOP é mais problemático do que parece e onde está realmente o seu problema. Se quer ficar com a posição de que OOP é ótimo sempre, ok, mas não diga que não avisei :)
Melhor para bibliotecas ou sistemas complexos
A minha opinião sempre (cerca de 30 anos) foi que OOP é melhor aplicada à bibliotecas e APIs. Não só, claro, mas principalmente. E mesmo assim não em todos casos de bibliotecas. Pra mim OOP brilha em problemas onde o PHP não costuma passar perto, mas em pontos específicos o PHP pode se beneficiar do paradigma.
Por sorte muitas vezes a pessoa acha que está usando OOP e está apenas usando uma classe simples que funciona como um módulo ou uma estrutura simples. A parte ruim é que ela acertou por coincidência. Usar classe não significa que está fazendo OOP.
Consumir APIs que foram construídas com OOP não é a mesma coisa que programar orientado a objeto.
Abstração e reuso
Concordo que é comum vermos as pessoas fazerem tudo o que o utluiz diz na sua resposta quando programam procedural. Mas também já vi pessoas botarem tudo em classes e cometerem erros piores. Veja (aqui mesmo no site) a maioria dos códigos comuns que as pessoas escrevem em OOP que fazem uma bagunça muito maior que o citado. Ela amontoa o que não pode e retalha o que não dá, é algo quase aleatório.
Talvez a explicação esteja certa se fizer puramente procedural do jeito que se fazia nos anos 60/70, mas não é o caso de fazer assim. Modularizar é algo importante, fazer tudo virar objeto nem tanto. Falo muito sobre o assunto em outra pergunta.
C é uma das poucas linguagens que não implementam nenhuma facilidade de OOP e a cultura é não tentar forçar este paradigma nela. As pessoas programam muito bem nela sem este paradigma nos sistemas mais complexos possíveis e não têm as dificuldades e erros citados (nem na versão antiga, nem na versão nova da resposta do utluiz). O "problema" da linguagem é ser muito baixo nível e o que mais faz falta pra ela é generacidade e um pouco mais de capacidade de modularização. Tá, também há a cultura de escrever código mneumônico, mas isto mudou bastante. Falta ser mais estática do que ela é. Em C e outras linguagens você resolve tudo o que foi citado sem dificuldades.
Tem um tipo específico de reuso não citado na resposta dele que realmente OOP ajuda, não vou entrar em detalhes para não alongar.
PHP é uma linguagem bastante dinâmica e se a pessoa souber o que está fazendo consegue muito reuso sem usar OOP. Na verdade pode obter até mais aproveitando bem os recursos dinâmicos da linguagem. Reforço que não estou dizendo que OOP não deva ser usado nunca.
Abstração é algo bom, e ela é usada desde que existe computador, OOP não inventou isto.
O problema não é o paradigma OO ou procedural, ou outro, é não saber usar a ferramenta. E algumas pessoas vendem OOP como se fosse algo que você usa e tudo se resolve. Mesmo que não seja a intenção delas acabam fazendo isto sem perceber. Muitas pessoas leem que OOP organiza o código e ela passa adotar o paradigma como se ele fosse mágico. Quem disse talvez saiba que não é bem assim, quem lê e ainda está aprendendo não percebe as nuances, não entende que não é panaceia.
Exemplo usado
O problema da manutenção citado nessa seção da resposta dele, ocorre nos dois paradigmas. OOP tem até um princípio que diz que você não deve modificar suas classes. Obviamente não dá para seguir sempre este princípio, mudanças provocam dificuldades em todos paradigmas.
O problema citado realmente existe por um defeito da linguagem, por isto citei C que não tem esse defeito. Realmente PHP não tem uma estrutura de dados simples meio termo. Ou você tem um array associativo dinâmico que produz o problema que ele citou ou tem a classe que resolve o problema específico. Mas este é um problema de coisa mais estática e mais dinâmica, não é uma dicotomia entre procedural e OOP.
Pois bem, use a classe então. porque você colocou em uma classe, está fazendo OOP? Então C é OO também, ela tem struct. Claro que discordo disto, todos discordam.
Não vou repetir todos os detalhes do que já disse em inúmeras respostas, algumas citadas aqui, OOP é mais do que criar uma classe. Colocar dados em uma estrutura eu sempre achei útil, éstá usando OOP assim?
enviar_email_cliente($JoseDaSilva); //esta variável é baseada em uma estrutura

Dá para fazer melhor que isto, mas não quis modificar o exemplo que seria ruim até em OOP.
Não tem nada de OOP aí. Se esta variável tem uma estrutura definida com AA ou com classe não é um detalhe importante (internamente no PHP vai dar no mesmo). Escolha qual achar melhor para seu propósito, mas o problema de manutenção da estrutura está resolvido. Os exemplos citados criam problema por fazer do jeito errado.
Quer que o IDE auxilie? Ok, use a classe para criar a estrutura. Só que o IDE vai ajudar porque ficou mais estático e não porque fez OOP.
Teve paciência de chegar até aqui? Então vai adorar esse blog que tem um bom artigo sobre essa questão. O Steve é o cara que pode espantar a maioria dos leitores, mas pelo menos ele não gera confusão com superficialismos, que eu sei que as pessoas preferem. Não preciso dizer que sou fã dele apesar de não concordar com tudo o que ele fala.
Estamos criando uma dicotomia entre paradigmas quando na verdade a questão é sobre tipagem. PHP teria muito mais robustez e facilidades de manutenção por ter tipagem estática do que por usar OOP. E se tirarem a tipagem dinâmica ela perde seu maior mérito. Já repeti várias vezes que se é para ter essa robustez toda não use PHP. Forçar o uso de tipagem estática e orientação a objeto é deturpar o que esta linguagem sempre teve de bom e diferente de outras soluções. Ter como opção para algumas coisas é bem útil.
Fluxo de chamadas de funções

Na resposta original havia algo sobre isto, veja: https://pt.stackoverflow.com/revisions/108209/1

Não vejo como o problema citado seja resolvido por OOP. Na verdade acho que não só OOP, mas toda modularização ajuda a piorar o problema. Também não prego fazer "linguições" para evitar o problema citado, que é real.
É possível resolver tão bem quanto OOP sem usá-lo, mantendo uma sintaxe limpa e organizada. Se as pessoas não sabem como fazê-lo é outro problema, mas elas também não sabem pra que serve um construtor, muito usado em OOP.
Variáveis globais

Aqui também é sobre a versão original

Um problema real, mas OOP não o resolve, há problemas que precisam do estado global.
A variável global tem outro problema: ter escopo global.
Há problemas que ou você complica o design ou faz algo que no fundo usa escopo global, mesmo que disfarçado. O problema do escopo global é quando ele é desnecessário e é usado assim mesmo. Há problemas que são inerentemente globais.
Em PHP mesmo o abuso de globais causa pouco problema porque eles são efêmeros. Claro que pode causar algum, mas pode ser uma solução simples também. E vou repetir mais uma vez, pode causar problemas usando qualquer ferramenta.
Em outro contexto eu acharia as globais mais perigosas.
Não vou me alongar, mais sobre o assunto:

Variável global personalizada
$GLOBALS para armazenar configurações?
Como usar variáveis estáticas e globais em PHP?

Exemplo prático

Baseado na resposta original do utluiz

Não gosto deste exemplo porque é comparação de uma implementação errada com uma certa. Não de um paradigma com outro. O exemplo mostra como não fazer de forma procedural e como fazer OO, é uma comparação injusta.
Mas não é culpa dele fazer isto. É difícil dar bons exemplos simples que o paradigma em si ajuda de forma clara.
Eu entendo que em OOP é mais difícil cometer este erro, mas é mais fácil cometer outros, e até piores. Note que a diferença de ser mais difícil e mais fácil é irrisória.
Exemplo sem classe e sem problemas.
$time = Timer();
gerar_relatorio();
Stop($time);

Pronto, não criou uma classe e dá tudo certo.
Tem linguagem que permitiria usar $time->Stop(). Aí é defeito da linguagem e não do paradigma. É só sintaxe, não muda a semântica, não muda o paradigma.
Tem outro exemplo que posso fazer sem usar classe que faria algo semelhante. A sintaxe não ficará boa em PHP, novamente é um problema da linguagem.
Eu resolvo isto de forma funcional melhor que procedural ou OO, mas funcional não tá na moda, e não é bem-vindo em PHP. Em pseudocódigo:
Timer(gerar_relatorio, print) //é um exemplo, pode ser de outra forma, print é opcional

De qualquer forma, Timer é algo da aplicação ou de biblioteca? Isto ajuda fundamentar o que eu disse no começo. Nem acho que seja o caso de Timer que pode funcionar bem sem OOP, mas OOP é melhor aplicado à bibliotecas, gerais ou de aplicação específica.
Usar a classe Timer pronta está programando OO ou só consumindo algo que por acaso foi feito assim?
Esse Timer tem que ser bem escrito em procedural ou OOP, senão a comparação não é justa. Se ele precisa ter mais dados, ok, crie uma estrutura de dados para isso, mas isto não é OOP.
Possivelmente eu até usaria OOP para criar um timer flexível. Mas em PHP 99% do tempo as pessoas não estão fazendo bibliotecas, ou ERPs, ou dev tool, ou outras soluções complexas "monolíticas". PHP roda scripts!
Encapsulamento
A seção cita variáveis globais, mas não vi nenhuma no código. Não vi vazamento de memória, vi um código mal escrito. E OOP não faz as pessoas magicamente escreverem códigos bem escritos.
Uma pessoa pode saber fazer bem em OOP e mal em procedural. Isto pode ocorrer, tem gente que só aprendeu fazer de um jeito. Tem pouco material ensinando fazer procedural certo, o legado do procedural realmente não é bom.
Mas o que vejo mais (a realidade de alguns privilegiados não pode ser posta para todos) é a pessoa não saber fazer dos dois jeitos. Este site tem um bom universo estatístico para comprovarmos isto. O procedural é mais simples dela aprender.
Precisa encapsular? Ok, sou favorável sempre, ainda que nem sempre seja tão necessário quanto acham. Só encapsular não é OOP, diversos paradigmas pregam isto.
As mudanças incompatíveis citadas ocorreram porque o código foi mal escrito. Se escrever mal OOP a incompatibilidade também ocorrerá. A resposta cita que o correto encapsulamento vai resolver um problema. Vale o mesmo para o procedural, fazendo o correto não tem problema algum.
A solução é dada por fazer corretamente e não porque usou OOP ou procedural. OOP não ajuda nada neste ponto, a não ser que a pessoa esteja acostumada fazer OOP e não tenha ideia de como fazer o mesmo em procedural, aí é uma questão cultural individual.
Pra falar a verdade achei que a versão nova da resposta até tenta vender, mesmo que não seja intencional, OOP como uma solução mágica para todos os problemas. Tem um monte de regra para seguir fazendo OOP para tudo dar certo. Então aplique um monte de regra em procedural e tudo dará certo. É muito comum os proponentes justificarem que OOP não está dando certo porque as pessoas não sabem fazer certo. Procedural também.
Em uma linguagem de script o encapsulamento se dá principalmente pela contenção do código em arquivos fontes que serão carregados sob demanda e que executarão e serão descartados em seguida. Quer mais granularidade? Tem como, é só saber organizar, como também é necessário saber em OOP.
Eu sei que pode ser uma simplificação, mas parece que a resposta vende um pouco a ideia que OOP é encapsular. Pode não ser intencional, eu sei. Encapsulamento faz parte de diversos paradigmas, OOP não pode tomar propriedade para ele.
No procedural também podemos mudar a estrutura interna sem afetar os consumidores, basta fazer certo. OOP também só entrega o que promete se fizer certo.
Eu ia fazer a versão procedural do novo Timer OOP da resposta, mas achei ele tão confuso que resolvi não arriscar :) Não entendi qual seria a intenção ali. Me parece que é OOP ruim também, mas posso estar enganado por não ter visto todo o contexto, parece que o código mistura responsabilidades.
Entidades
Acho pouco relevante como a entidade é representada. Em PHP classes no fundo são arrays associativos, ainda que a implementação difira um pouco do AA padrão da linguagem. Em diversas situações não é possível determinar se tudo o que está na classe está sendo feita de forma correta. A impressão que eu tenho é que a resposta não considera a realidade do PHP. Para fazer tudo o que ela prega PHP teria que ter uma classe de forma mais estática do que é, você não pode garantir o que não é estático.
A criação de classes pode burocratizar um pouco o desenvolvimento, o que é bom em grande parte das aplicações feitas em Java, por exemplo. Mas PHP é uma linguagem com menos cerimônia. Falo muito sobre isto em outra pergunta.
Admito que pessoas muito desorganizadas podem encontrar em OOP alguma salvação, mas ela pode se dar mal optando por isso. Vejo perguntas aqui no site onde a pessoa começou fazendo mais procedural e ela errava, passou fazer OOP e ficou muito pior. As pessoas estão sendo "obrigadas" a usar OOP, ninguém quer ficar de fora disto que todo mundo está usando.
Curiosamente em OOP hora se prega para juntar tudo, hora se prega para separar. Sim, tem que fazer os dois, mas é o que eu sempre digo, usar uma regra geral para casos específicos não dá certo. Então muito do que se diz de benefício de OOP não significa muita coisa quando vai codificar o problema real. Fica lindo na teoria e péssimo na prática. Aí quem domina a ferramenta que é complexa faz certo, quem não domina se atrapalha mais.
Novamente, tem casos onde pode haver ganhos. O problema é que é difícil dizer sem conhecer o caso específico profundamente, coisa que levaria horas, dias, nunca poderá ser respondido aqui.
Pegando o exemplo específico (da resposta original), quem garante que a validação dentro da classe será chamada por ela mesma ou externamente? Quem garante que aquela validação pode ser usada em todas situações? Quem garante que o sistema pode trabalhar bem com o objeto sempre em estado válido único? Eu poderia continuar fazendo vários questionamentos. OOP não garante nada a mais, nem quando bem feito, mas o bem feito em qualquer paradigma pode dar melhores garantias em grande parte das situações.
Adicionar campos novos é mais fácil em uma estrutura mais dinâmica do que em uma classe, ainda que em PHP a classe possa ser dinamizada.
Todos os problemas citados podem ocorrer em qualquer paradigma e nenhum ajuda fazer melhor o que foi mal feito.
OOP traz problemas novos, por isso explodiram os tais dos design patterns famosos. A maioria deles foram criados para resolver os problemas de OOP, que não existem se usar o PHP "tradicional". Aplique padrões específicos para o procedural e os problemas dele serão resolvidos.
Eu acho que se tivesse um livro canônico e popular, talvez chamado "Design Patterns para Procedural" :P e ele tivesse vindo antes de OOP, este último não teria este sucesso todo. É bem um talvez, porque o advento da GUI quase obrigou OOP existir. E aí entra onde OOP deveria ser usado mesmo, coisa longe do PHP. OOP faz mais sentido em JS que PHP.
Cuidado para não confundir paradigmas com padrões de projeto, nem com tipagem.
Muitas das vantagens e desvantagens que as pessoas veem em OOP (nem todas, claro) está mais ligado à linguagem ser estática do que ser orientada a objeto. Curiosamente OOP puro (aquele do Smalltalk) funciona melhor em linguagens dinâmicas, e não dá todas as garantias citadas. Os problemas citados não existe em C que é procedural, mas é estático.
Se PHP não ajuda garantir muita coisa é uma falácia dizer que alguma coisa será garantida se usar o paradigma. Mais uma vez, a garantia virá do uso correto de qualquer paradigma, que é muito subjetivo. Ou da tipagem estática, que é algo que a classe começou introduzir em PHP. Se ela tivesse sido chamada de struct e não class, aceitariam que não é OOP? Falo da classe como um container de dados, só, sem outros apetrechos. Os apetrechos fazem ser OOP.
A versão nova da resposta tem exemplos novos, mas é repetição do que eu já disse, não vou comentar especificamente.
O potencial do PHP em diferentes paradigmas
Concordo com quase tudo nesta seção, faço algumas ressalvas ou ressaltos.
PHP costuma ser usada para coisas relativamente triviais. É uma linguagem de script.
Imperativo é diferente de procedural ou funcional, que também são diferentes entre si. Não é só que um usa procedimentos e outro usa funções, bem longe disto definir estes paradigmas (não vou entrar em detalhes, quem tiver dúvida, faça perguntas específicas).
Imperativo realmente não vai desaparecer e é totalmente ortogonal com vários outros paradigmas, incluindo OOP.
Procedural também é ortogonal, mas nem tanto. A maneira de organizar um ou outro é diferente, em certo ponto específico você escolhe um ou outro, mas pode misturá-los na aplicação como um todo.
Eu vejo as pessoas realmente tendo muito problema com OOP, em todas as linguagens. OOP não é tão simples quanto vendem. É verdade que as pessoas também têm problemas com procedural, mas é porque elas não aprenderam desenvolver softwares de uma maneira geral e isto, me parece, ocorre mais em PHP que outras linguagens. Até vejo mais ainda em webdev em geral, parece haver "paraquedismo" maior nesta área.
Concordo 100% que procedural é mais fácil e como ele costuma resolver sem problema algum a maioria dos problemas que o PHP costuma trabalhar ele deve ser a opção default, pelo menos de quem não tem OOP como seu paradigma fundamental e que o domine absolutamente, o que talvez até seja um caso de martelo dourado. Tentar fazer o que não entende é pior que fazer com a "melhor ferramenta".
Me escute! Prefira um machado do que uma motosserra se não souber usar uma. Mesmo que não saiba usar o machado também, e de qualquer jeito tenha que cortar a árvore. Claro que eu prefiro que aprenda usar ambos antes de fazer isto, mas isto ninguém escuta. Uma pessoa bem treinada no machado será bem rápida e não vai machucar-se. Na motosserra ela morrerá antes de conseguir treinamento adequado. Eu falo isto e as pessoas não escutam. Vejo isto o tempo todo. E as pessoas que são bem treinadas costumam incentivar o sujeito a largar o machado e ir pra motosserra achando que elas vão autotreinar-se magicamente, afinal elas conseguiram fazer isto e acham que todo mundo consegue fazer o mesmo. Bem treinado e na árvore certa é possível beneficiar-se da motosserra. Embora o risco sempre será maior e quando erar o estrago também será. É claro que estou falando de procedural e OOP ainda. Parece que lenhadores são mais espertos que programadores, eles usam os dois.
Ultimamente tenho percebido que quem aprende OOP primeiro, e até bem, tem dificuldade de entender procedural corretamente, talvez até por ela ter uma visão do que OOP é, que, no mínimo, eu discordo.
Polêmica
No campo absolutamente pessoal então não tome isto como verdade absoluta.
Eu acho que muitos proponentes de OOP devem ter lido algum livro que vendeu OOP de forma marketeira. Esta forma coloca OOP de forma tão genérica que a sua definição serve para boa parte dos paradigmas, ou seja, ela fala sobre organizar código.
Se for isso, então eu programo OOP há mais de 30 anos em tudo que faço, antes de ter alguma linguagem mainstream suportando isto "oficialmente" e eu nunca ter ouvido falar no termo.
Mas acho que OOP é muito mais que isto, e a maioria das definições sobre OOP encontradas colocam requisitos muito maiores que os citados genericamente. Pra mim a definição genérica de OOP é essencialmente a mesma da modularização. Ou seja, ela tenta "sequestrar" algo que não é dela. Assim como músicas de qualidade questionável, como "funk", "sertanejo", e "pagode" que usam nomes de outros gêneros musicais originais e mais antigos, que tinham qualidade, para tentar se validar.
OOP não tem méritos próprios?
Dentro da especificação mais estrita eu acho OOP bem válido para vários problemas. Quando se diz que OOP é só uma forma de encapsular, de por as coisas juntas, de separar responsabilidades, fazer reuso de forma geral, de abstrair, pra mim é outro paradigma. OOP não pode pegar o que está presente em outros paradigmas, não colocar mais nada e dizer que é algo diferente. Não pode dizer que só colocar o substantivo na frente do verbo seja uma inovação que muda o paradigma. Isso é só sintaxe, dá pra fazer isto no procedural.
Ah, polimorfismo puro não dá a robustez esperada. Ele implementado de forma estática é que dá.
Em perguntas citadas aqui eu falo com mais detalhes sobre o que eu e muita gente vê em OOP.
Discorda disto? Ok. Eu sei que existem duas vertentes do que é OOP, aceito isto. Espero que quem discorda aceite isto também e não tenha a sua verdade como absoluta. Tem perguntas sobre o assunto, vá lá, discorde e fundamente o que pensa.
Conclusão
É um direito de cada um procurar o que elas acham melhor pra si, só quis colocar outra perspectiva. Em nenhum momento digo que está errado usar OOP, pelo contrário, eu o uso.

Faça o que você domina e se sinta mais confortável.
Comece pelo simples, e vá procurando soluções para os problemas quando for percebendo que eles surgem.
Não resolva um problema que não existe.
Dê uma passo de cada vez.
Não force o uso de uma paradigma sem necessidade.
Entenda o que está fazendo, não siga receitas.
Não faça porque todo mundo está fazendo.
Se questione se está tomando a decisão certa. Questione pessoas mais experientes com dúvidas específicas. Aproveite a experiência delas para acelerar a sua, mas não queime etapas.

Eu acho justo a pessoa querer evoluir, dominar novas ferramentas, entender tudo o que ela pode fazer. O que eu acho estranho é quando a pessoa decide o que é bom pra ela sem entender como usa aquilo direito, e passa ignorar outras formas que podem ser melhores. E desiste de evoluir de outro jeito que pode ser melhor pra ela.
A maior falácia que vejo sobre OOP é que isto organiza códigos. Ele ajuda! Como outras coisas ajudam. Quem sabe o que está fazendo fará bem em qualquer paradigma, quem não sabe produzirá um desastre em qualquer paradigma, mas será mais fácil produzir desastres em um que ele não domina.
Hoje vejo que a pessoa não aprende bem o procedural porque não há incentivo em aprender bem e não aprende bem OOP porque ele é mais difícil de aprender "certo".
Tem coisa que faz diferença usar um processador de alimentos ou um liquidificador. Tem coisa que dá na mesma.
Por que tem gente que prefere conscientemente usar a faca se o processador é tão bom? Por que usar lâmina de barbear se a máquina é melhor? Por que usar o telefone fixo se o celular resolve tudo? Por que usar outros paradigmas se OOP resolve o problema melhor que eles?
Fora estes frameworks complexos - e eu questiono bastante o uso deles em PHP - e alguns casos bem específicos, eu raramente vejo uso válido para OOP em PHP no nicho onde ele brilha.
Então abaixo dou um exemplo de como eu aplicaria OOP em um website comum em PHP:

:)
Coloquei no GitHub para referência futura.
Comment: Como ninguém que negativa está dizendo porque fica claro que só pode ser: A) a pessoa não entende do assunto e acha que eu estou errado, se ela tem certeza que estou errado, ela falaria onde tem erro; B) Ela apenas discorda e acha que o voto serve para demonstrar isto; C) Apenas não gosta de mim e acha que eu mereço punição.
Comment: Estranho o voto negativo. +1 para fazer justiça. Concordo com tudo, salvo algumas poucas observações que farei na minha resposta atualizada.
Comment: Esse último exemplo foi show hein kkk.. Obrigado pela resposta e pelos links, deu para fundamentar um pouco mais do conteúdo. Eu pessoalmente uso OOP apenas quando tenho um código bem massivo como de banco de dados, o resto faço sem mesmo usar funções, pois realmente discordo de algumas coisas que já li, que dizem ser melhor usar OOP em 100% do seu projeto fica organizado e blábláblá. Eu creio que depende do programador ter um código organizado e adequado e não de um padrão, etc. Obrigado aos dois que responderam, ambas respostas foram boas e complementais para o assunto, obrigado.
Comment: @Edilson ok, respeito sua opinião. Eu discordo obviamente. Concordo que pode ter ficado um pouco confuso porque tem duas versões da resposta do utluiz. O que pode parecer contraditório é que eu não sou anti-OOP como alguns acham. Eu mostro que ele tem problemas, mas não é algo horrível que nunca deva ser usado. Ser imparcial não é fácil. Eu sei que as pessoas querem que se tome partido. Mas eu não faço isto. O que você percebe sobre o que está escrito é um problema exclusivamente seu. Eu sei o que eu sinto. Obrigado por justificar seu voto, pelo menos eu sei porque ele foi dado.
Comment: Claramente você viu coisas no texto que não existem, como o fez com o texto do utluiz, então não vale a pena nem tentar debater ponto  por ponto dos seus comentários, não vai levar a lugar algum. Eu encontro alguns erros conceituais no que está dizendo, e se eu tentar isto vai ficar longo demais. Você fez um relato pessoal, não quer dizer que seja válido para outras pessoas. Não lembro da pergunta sobre *patterns*, mas acho muito pouco provável que eu tenho dito o que está afirmando, eu acho que disse algo parecido e você entendeu outra coisa, parece ser comum isto acontecer.
Comment: Dessa vez fui eu quem negativou, a edição que fizeste e mais algumas partes, contrariam grande parte do que escreveste, várias e várias, e deixa pouco claro o objectivo, e grande parte do que escreveste parece o diário de alguém enfurecido, tu mesmo disseste que cada um deve usar o que melhor domina, muita gente concorda, e é sabido que grande parte não domina OOP tanto em PHP, au até mesmo nas linguagens baseadas nesse paradigma. O que já foi antes dito continua a ser válido, OOP é tópico avançado, as pessoas usam porque querem, não porque foram obrigadas.  ->
Comment: O quê ? **<>** ? Estes passam praticamente a fazer parte de uma cadeia diferente, só temos de aprender os métodos e voilá contruímos aplicações web/desktop sem problemas. Aplicações continuam a poder ser feitas com PHP normal, ou se quisermos algo um bocadinho maior, tiramos algum partido do que o OOP tem para oferecer. Em várias perguntas minhas, deves ter lido uma parte onde eu dizia que **"não estou habituado a trabalhar com OOP muito menos frameworks "**, E realmente não. Conheço pouco, mas safo-me com o paradigma, e posso afirmar que uso OOP sem problemas quando preciso. ->
Comment: Novatos a tentar criar programas usando conceitos avançados quando mal dominam o básico da linguagem, não é novidade. O facto de OOP ter sido vendido às pessoas ? Não discordo e também não  concordo, fico pela metade. É sabido que grande parte das pessoas usa OOP por pensar que ajuda a resolver grande parte dos problemas que encontrou quando tentou programar da forma funcional, e o OOP parametriza o resto e atira o problema algures para fora do campo de visão do programador ou, até mesmo, o erro continua lá, e ele mal dá pelo erro e ignora, uma vez mais, É culpa o OOP ? ->
Comment: Eu várias vezes tiro partido do OOP para resolver problemas que encontrei quando usei diferentes abordagens, tanto funcional como prodecural, não que não soubesse como resolver usando usando alguma das abordagens anteriormente experimentadas, mas acabei por reescrever a aplicação usando OOP por causa daquele problema específico. Porquê fiz isso ? Simples, analisei quais outros problemas teria se continuasse a trabalhar daquela maneira, comparei em qual dos casos teria mais benefício e prontos, além de prever o mesmo problema em diferentes fases. ->
Comment: Resolver problemas sem usar OOP é bastante fácil, muito mesmo, mas nem sempre é a maravilha como várias pessoas descrevem, pode ser em grande parte dos casos, mas não em todos. Programar com OOP tem imensas vantagens, mas tais vantagens passam desapercebidas pelos amadores - não todos - e acabam por usar OOP por "pensarem coisas" e acabam fazendo o que fazem. Generalizar o problema relativo ao mau uso não é solução. Há já algum tempo fiz uma pergunta onde questionava se o MVC era solução para vários problemas de programação , e a pergunta foi  **considerada não construtiva** e encerrada. ->
Comment: Lembro-me ainda que em uma das minhas perguntas aqui no SOpt, sobre o uso dos patterns, não só te limitaste a dizer que não são solução, como não deveria fazer o uso deles. Passado algum tempo apercebi-me que **patterns** são apenas **práticas testadas e recomendas** - grande novidade -.-' - , nesse mesmo instante apercebi-me também que eu já antes usava patterns. Disseste que encapsular não é relativo à OOP apenas, como grande parte pensa, e nisso tens razão, e quanto aos ** singletons** ? São exclusivos ao OOP ? Vês a ideia ?
Comment: Uma vez mais, não quis provar nada, só dizer o que penso, e o que senti ao ler o que escreveste. Tal como várias linguagens são escolhidas de acordo com o que podem proporcionar de forma mais eficiente em relação à outras, acho que o PHP safa-se bem com as tarefas que lhe são atribuídas.
Comment: Eu não disse o que disse para debater, apenas quis dizer o que achei da tua resposta. **"Claramente você viu coisas no texto que não existem"** - diferente da resposta anterior, dantes eu não a tinha lido, mas essa eu li, de uma ponta para outra. Se você encontrou erros ou algo parecido é justificável, mas nada foi inventado. Sobre os patterns, o que eu quis dizer, é que eles já existiam, e as pessoas às vezes usam patterns mesmo sem saber o que são, e nem sempre vêm como patterns - isso no contexto actual - embora para o OOP estes ganharam mais destaque devido aos "erros" da pessoa.
Comment: Muito bom! Obrigado pelos outros conteúdos, inclusive o vídeo!
Comment: Hoje eu entendo o porque você bate tanto no uso do OOP no PHP. Espero não estar equivocado, mas entendo que OOP é ferramenta para facilitar a reusabilidade do código e, principalmente, em linguagens de script são feitos feitos uso de classes e objetos que não são OOP que na verdade acabam complicando desnecessariamente um código.


Problema em mudar a Posição do jogador para outra posição no tile em p5.js

Question: Boas pessoal estou com um pequeno problema eu quero que o jogador passe para a posição 2 do tile mas mas na hora que carrego numa tecla ele da erro a dizer " is not a function não mostrando o jogador. como posso resolver esse problema? Este código foi desenvolvido em p5.js
O código é o seguinte:
<code>var jog = 0;

var tls = new Array(4);

function setup() {
    createCanvas(400, 400);
    background(220);
    for (var i = 0; i < tls.length; i++) {
        tls[i] = new tile(100 + ((i + 1) * 60), 100, i);
        tls[i].showTiles();
    }
    pl1 = new plr(1);
    pl2 = new plr(2);
    pl3 = new plr(3);
    pl4 = new plr(4);
}

function draw() {
    for (var i = 0; i < tls.length; i++) {
       tls[i].showPlrs();
    }
}

function mousePressed() {
    tls[0].startGame();
}

function keyPressed() {
    //Problema está aqui
    pl1.setTileCount(2);
    pl1.showPlayers();
}

class tile {

    constructor(x, y, id) {

        this.id = id;
        this.centerPos = createVector(x, y);
        this.plrs = [];
        this.posPlayer1 = createVector(this.centerPos.x - 5, this.centerPos.y - 5);
        this.posPlayer2 = createVector(this.centerPos.x + 5, this.centerPos.y - 5);
        this.posPlayer3 = createVector(this.centerPos.x - 5, this.centerPos.y + 5);
        this.posPlayer4 = createVector(this.centerPos.x + 5, this.centerPos.y + 5);

    }

    showTiles() {

        rectMode(CENTER);
        rect(this.centerPos.x, this.centerPos.y, 50, 100);
    }

    showPlrs() {
        if (this.plrs.length != 0) {
            for (var i = 0; i < this.plrs.length; i++){
                console.log(this.id);

                if (this.plrs[i].getId() == 1 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer1.x, this.posPlayer1.y, 5);
                } else if (this.plrs[i].getId() == 2 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer2.x, this.posPlayer2.y, 5);
                } else if (this.plrs[i].getId() == 3 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer3.x, this.posPlayer3.y, 5);
                } else if (this.plrs[i].getId() == 4 && this.id == this.plrs[i].getTileID())
                    circle(this.posPlayer4.x, this.posPlayer4.y, 5);
            }
        }
    }

    startGame() {
        this.plrs.push(pl1);
        this.plrs.push(pl2);
        this.plrs.push(pl3);
        this.plrs.push(pl4);
    }
}

class plr {
    constructor(id) {
        this.id = id;
        this.tileID = 0;
    }

    getId() {
        return this.id;
    }

    setTileCount(diceResult) {
        this.tileID = this.tileID + diceResult;
    }

    getTileID() {
        return this.tileID;
    }
}
</code>
Answer: E claro que não ia funcionar, você precisa definir a classes primeiro e depois você usa elas, senão o Javascript não vai saber onde encontrar a classe
<code>//////////////////////////////////////////////////////////////////////////////
class tile {

    constructor(x, y, id) {

        this.id = id;
        this.centerPos = createVector(x, y);
        this.plrs = [];
        this.posPlayer1 = createVector(this.centerPos.x - 5, this.centerPos.y - 5);
        this.posPlayer2 = createVector(this.centerPos.x + 5, this.centerPos.y - 5);
        this.posPlayer3 = createVector(this.centerPos.x - 5, this.centerPos.y + 5);
        this.posPlayer4 = createVector(this.centerPos.x + 5, this.centerPos.y + 5);

    }

    showTiles() {

        rectMode(CENTER);
        rect(this.centerPos.x, this.centerPos.y, 50, 100);
    }

    showPlrs() {
        if (this.plrs.length != 0) {
            for (var i = 0; i < this.plrs.length; i++){
                console.log(this.id);

                if (this.plrs[i].getId() == 1 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer1.x, this.posPlayer1.y, 5);
                } else if (this.plrs[i].getId() == 2 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer2.x, this.posPlayer2.y, 5);
                } else if (this.plrs[i].getId() == 3 && this.id == this.plrs[i].getTileID()) {
                    circle(this.posPlayer3.x, this.posPlayer3.y, 5);
                } else if (this.plrs[i].getId() == 4 && this.id == this.plrs[i].getTileID())
                    circle(this.posPlayer4.x, this.posPlayer4.y, 5);
            }
        }
    }

    startGame() {
        this.plrs.push(pl1);
        this.plrs.push(pl2);
        this.plrs.push(pl3);
        this.plrs.push(pl4);
    }
}

class plr {
    constructor(id) {
        this.id = id;
        this.tileID = 0;
    }

    getId() {
        return this.id;
    }

    setTileCount(diceResult) {
        this.tileID = this.tileID + diceResult;
    }

    getTileID() {
        return this.tileID;
    }
}
///////////////////////////////////////////////////////////////////////////////////

var jog = 0;

var tls = new Array(4);

function setup() {
    createCanvas(400, 400);
    background(220);
    for (var i = 0; i < tls.length; i++) {
        tls[i] = new tile(100 + ((i + 1) * 60), 100, i);
        tls[i].showTiles();
    }
    pl1 = new plr(1);
    pl2 = new plr(2);
    pl3 = new plr(3);
    pl4 = new plr(4);
}

function draw() {
    for (var i = 0; i < tls.length; i++) {
       tls[i].showPlrs();
    }
}

function mousePressed() {
    tls[0].startGame();
}

function keyPressed() {
    //Problema está aqui
    pl1.setTileCount(2);
    pl1.showPlayers();
}
</code>


How do I programmatically set a taxonomy term for a node?

Question: I got some difficulties setting a taxonomy for a node. Currently I am using this code.
$node = Node::create(array(
    'type' => 'detailseite',
    'title' => $data[$headlineIndex],
    'langcode' => 'de',
    'uid' => '1',
    'status' => 1,
    'field_headline' => $data[$headlineIndex],
    'field_intro' => $data[$introIndex] . $categories[$data[$categoryIndex]],
    'created' => $data[$dateIndex],
    'field_autor' => $data[$autorIndex],
    'field_teaser_text' => $data[$shortIndex],
    'field_fields' => array(),
));
$node->save();

Which works fine so far (below an image of the fields of "detailseite").

Everything gets set correctly and I can find the newly created nodes in the admin area that work correctly.
Now I need to set 'field_meldungstyp' which is an Entity-Reference to a Taxonomy:

which already contains three entries:
I want to get the node(s) I created programmatically to have "field_meldungstyp" set to "Artikel" of the "Meldungstyp"-Vocabulary.
I already tried adding:
'field_meldungstyp' => array( 'tid' => 19 ),

where 19 is the tid of "Artikel" of the earlier mentioned vocabulary. And that's where I'm stuck.
Also https ://www.drupal.org/node/2402811 didn't work for me. As well as
$node->field_meldungstyp[$node->language][]['tid'] = 19;

didn't work either.
simply adding
$node = Node::create(array(
    ...
    'field_meldungstyp' => 19,
    ...
));

results in crashing with the following error:

Drupal\Core\Entity\EntityStorageException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'datetime' for column 'created' at row 1: INSERT INTO {taxonomy_index} (nid, tid, status, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 343 [:db_insert_placeholder_1] => 19 [:db_insert_placeholder_2] => 1 [:db_insert_placeholder_3] => 0 [:db_insert_placeholder_4] => datetime ) in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save() (line 770 of core/lib/Drupal/Core/Entity/Sql/SqlContentEntityStorage.php).
  Drupal\Core\Database\Statement->execute(Array, Array) (Line: 610)
  Drupal\Core\Database\Connection->query('INSERT INTO {taxonomy_index} (nid, tid, status, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4)', Array, Array) (Line: 81)
  Drupal\Core\Database\Driver\mysql\Connection->query('INSERT INTO {taxonomy_index} (nid, tid, status, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4)', Array, Array) (Line: 32)
  Drupal\Core\Database\Driver\mysql\Insert->execute() (Line: 371)
  Drupal\Core\Database\Query\Merge->execute() (Line: 525)
  taxonomy_build_node_index(Object) (Line: 479)
  taxonomy_node_insert(Object)
  call_user_func_array('taxonomy_node_insert', Array) (Line: 402)
  Drupal\Core\Extension\ModuleHandler->invokeAll('node_insert', Array) (Line: 167)
  Drupal\Core\Entity\EntityStorageBase->invokeHook('insert', Object) (Line: 418)
  Drupal\Core\Entity\ContentEntityStorageBase->invokeHook('insert', Object) (Line: 470)
  Drupal\Core\Entity\EntityStorageBase->doPostSave(Object, ) (Line: 304)
  Drupal\Core\Entity\ContentEntityStorageBase->doPostSave(Object, ) (Line: 395)
  Drupal\Core\Entity\EntityStorageBase->save(Object) (Line: 761)
  Drupal\Core\Entity\Sql\SqlContentEntityStorage->save(Object) (Line: 364)
  Drupal\Core\Entity\Entity->save() (Line: 46)
  Drupal\awo_importer\Controller\T3ImporterController->import()
  call_user_func_array(Array, Array) (Line: 123)
  Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}() (Line: 574)
  Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
  Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
  Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber{closure}()
  call_user_func_array(Object, Array) (Line: 144)
  Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
  Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
  Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 98)
  Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 77)
  Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
  Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
  Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
  Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 628)
  Drupal\Core\DrupalKernel->handle(Object) (Line: 19)
Answer: In Drupal 7, taxonomy reference fields existed which used the pattern ['tid' => NUMBER]. These are entity reference fields. The EntityReferenceItem has the property definitions: target_id and entity. The former is a either an integer or string depending on the entity reference item's settings (basically config/content entity type).
This is also a similar question to How to set value for multivalue field in drupal 8 programmatically
So try to use the pattern
As part of Entity::create
Node::create([
  'field_meldungstyp' => [['target_id' => 19]]
]);

Using FieldableEntityInterface::set
$entity->set('field_meldungstyp', ['target_id' => 19]);

Using TypedDataInterface::setValue on the field item directly.
$entity->field_meldungstyp->setValue(['target_id' => 19]);

With magic method
$entity->field_meldungstyp->target_id = 19;

Note that this overwrites any current values of the field.
Comment: "$entity->field_meldungstyp->value = [['target_id' => 19]];". That's not correct. What you want is $entity->field_meldungstyp->target_id = 19. Note that also just providing 19 without the array works for set(), setValue() and even $node->field-meldungstyp = 19 should work for a single value field. The field type will attempt to convert it into the correct stucture automatically.
Comment: I find [Content Entity](https://www.drupal.org/node/2143503) documentation a bit incomplete as it is not clear how to set a field item other than the value magic method. For base fields it's a string or integer, but field items it should include the full field item list values?
Comment: Unfortunately still results in -syntax error, unexpected '=', expecting ']'- for me when I add any of those right before $node->save. Even if I change the whole thing over to something like "entity_create('node', $node)" and removing Node::create, the line results in a crash. Maybe there is something wrong with my Drupal install itself of I'm missing something.
Comment: Did you see the syntax error in my answer? Correct it. It should be `=>` not `=`. :-)
Comment: I guess I really need a break ;D (working on that the whole day already), `=>` still gives me `syntax error, unexpected '=>' (T_DOUBLE_ARROW)`.
Comment: Got it to "work" now i.e. it doesn't crash on me any more but the field unfortunately still doesn't get set on the generated nodes.
Answer: It needs to be a nested array.
'field_meldungstyp'  => [
      ['target_id' => 12345]
    ]

Try this:
$node = Node::create(array(
    'type' => 'detailseite',
    'title' => $data[$headlineIndex],
    'langcode' => 'de',
    'uid' => '1',
    'status' => 1,
    'field_headline' => $data[$headlineIndex],
    'field_intro' => $data[$introIndex] . $categories[$data[$categoryIndex]],
    'created' => $data[$dateIndex],
    'field_autor' => $data[$autorIndex],
    'field_teaser_text' => $data[$shortIndex],
    'field_meldungstyp'  => [
      ['target_id' => 12345]
    ]
));
$node->save();

Comment: That somewhat crashes too with (I exchanged `12345` to `19` accordingly ;) )`Drupal\Core\Entity\EntityStorageException: SQLSTATE[HY000]: General error: 1366 Incorrect integer value: 'datetime' for column 'created' at row 1: INSERT INTO {taxonomy_index} (nid, tid, status, sticky, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4); Array ( [:db_insert_placeholder_0] => 188 [:db_insert_placeholder_1] => 19 [:db_insert_placeholder_2] => ... in Drupal\Core\Entity\Sql\SqlContentEntityStorage->save()`
Comment: you have an error with your "created" field, it needs to be a unix timestamp.  If you remove created from your array, the error will go away.  Try it.
Answer: Here is how i did it for D8.
use Drupal\node\Entity\Node;

//To create new node
$node = Node::create(['type' => 'YOUR_CONTENT_TYPE_HERE']);

//To load a node by its ID
//$node = \Drupal\node\Entity\Node::load(NODE_ID);

$nodeTerms = [1,2,3...]; // 1,2,3 = terms IDs
$node->set('YOUR_FIELD_OF_TERMS', $nodeTerms);
$node->save();

//To create new tax
use Drupal\taxonomy\Entity\Term;

$new_term = Term::create([
    'vid' => "YOUR_VOCABULARY_MACHINE_NAME",
    'name' => "NAME_OF_YOUR_TERM",
]);
$new_term->save();

Answer: Another approach would be to update the node after creation, like this:
$node = Node::create(array(
    ...
));
$node->save();
$node->field_meldungstyp->target_id = 19;
$node->save();

Comment: Tried that too initally and it crashed. I'll add the output to the top.
Comment: okey - so try target_id
Comment: Unfortunately same results/error-message. :(
Comment: Then I would update the field after creation (save) - updated my answer. Have you tried the nested array with the key target_id ?
Comment: Yeah, tried it, unfortunately same error as here [link[(http://drupal.stackexchange.com/questions/217396/how-do-i-programmatically-set-a-taxonomy-term-for-a-node/217400?noredirect=1#comment265592_217419)
Comment: okey - but thats while creation ? not while updating ?? In Node::create you should skip field_meldungstyp
Comment: Tried both ways to no avail unfortunately i.e. `'field_meldungstyp' => array(array('target_id' => 19)),` inside `Node::create` as well as without anything of `'field_meldungstyp` inside it but with `$node->save();
$node->field_meldungstyp->target_id = 19;
$node->save();` afterwards
Answer: Here's how I got this working in D9:
$node = \Drupal::entityTypeManager()->getStorage('node')->create([
  'type' => 'content type',
  'title' => 'node title',
  'field_tax_ref' => ['target_id' => '3'],
]);
$node->save();

field_tax_ref is a taxonomy entity reference field.
'3' is the tid of the term I want to reference.


Free ultrafilters on $\mathbb N$

Question: I need to show that if $U$ is a free ultrafilter on $\mathbb N$, then ($A \in U$ and $F \subseteq \mathbb N$ finite) $\implies (A\Delta F) \in U$.
To show this do you need maximality?  (Would the same hold for any non-principal/free filter; one such that the intersection of all its sets is empty?)
Answer: The complement $F'$ of our finite set is in $U$, because $U$ is non-principal. It follows that $A\cap F'\in U$. But the symmetric difference contains $A\cap F'$. We have not used maximality, except for the assertion that the complement of any $1$-element set is in the filter.
Comment: The answer sketched a proof that from complements of $1$-element sets one can get the result. (By finite intersection we can get complement of any finite set.) And we *need* complements of $1$-element sets, because if we pick $A=\mathbb{N}$ and $F$ a one element set, then the symmetric difference is precisely the complement of that $1$-element set.
Comment: Ok, how do you know that F' is in U?
Comment: I added an "except." We have used the fact that the complement of any $1$-element set is in the filter.
Comment: Ok, I see why "the complement of any 1-element set is in the filter" would suffice.  But maybe you don't need maximality... Suppose X\{x} not in U, for some x.  Then for all S in U, x must be in S (S cannot be a subset of X\{x}).
Comment: Given a non-principal filter $U$ on $\Bbb N$, why is it necessarily the case that complements of singletons are in the filter? Or are you simply reducing the maximality condition to the (possibly strictly) weaker assumption that complements of singletons are in the filter?
Comment: It is strictly a lot weaker. All we need to do is to add to the filter base the complements of singletons.
Comment: Certainly not, it is not true. Take for example a nice filter $V$ on the evens. Now make a filter $U$ on $\mathbb{N}$ by saying that $X\in V$ iff $X$ is the union of an element of $V$ and *all* the odds. Then the complement of $\{1\}$ is not in $U$.
Comment: Fantastic! Thank you very much. You've helped me realize a false assumption I'd been making about free filters--namely, that if $F$ is a free filter, then $\bigcap F=\emptyset$.
Answer: It's a nice result that an ultrafilter on an infinite set $X$ is non-principal if and only if every cofinite subset of $X$ is a member of the ultrafilter. Consequently, for every finite $F\subseteq\Bbb N$, we have $(\Bbb N\smallsetminus F)\in U$, so $A\cap(\Bbb N\smallsetminus F)\in U$, and since $A\cap(\Bbb N\smallsetminus F)\subseteq A\Delta F$, then $(A\Delta F)\in U$.
We don't need that whole result--only that non-principality of a filter implies that every cofinite subset of $\Bbb N$ is a member of the filter. If we can prove that this holds for arbitrary filters (not just ultrafilters), then maximality won't be necessary at all. I suspect, however, that this may not hold in general. I'll think on it and see if I can come up with another way to get there avoiding maximality.
Comment: I think I proved this in the comments below: Let F be a free filter on X. As Mr. Nicolas points out, to show F contains every cofinite subset, it suffices to show F contains complements of singletons. Suppose X\{x} not in F for some x. Then for all S in F, S cannot be a subset of X\{x} (else X\{x} is in F). So x must be in S (for each S) contradicting F free.
Comment: Actually, knowing that $x\in S$ for all $S\in F$ *doesn't* imply that $F$ isn't free. We **can't** actually show that free filters necessarily contain every cofinite subset. As an example (credit to Andre for this one), let $E$ denote the even natural numbers, suppose $V$ is a free filter on $E$--meaning $V$ is a non-empty set of subsets of $E$ with no $\subseteq$-least member--and define $$U=\bigl\{A\cup(\Bbb N\smallsetminus E):A\in V\bigr\}.$$ It can be shown that $U$ is a free filter on $\Bbb N$, but $1\in S$ for all $S\in U$.
Comment: (cont'd) Andre was actually pointing out that we need the additional assumption that the given free filter has every cofinite subset as a member, or we can't draw the desired conclusion. This is a strictly weaker assumption than maximality, but we do need it if we're working with arbitrary filters. *If* we're working with a free filter $F$ such that $\bigcap F=\emptyset$, then we *don't* need this assumption, but this isn't necessarily true of *all* free filters, as the above example shows.
Comment: Thanks, I did not understand the definition properly.  One final question: "free" and "non-principal" mean the same thing, right?
Comment: You're correct. Some sources use one, some the other, but they mean the same thing.
Comment: I did find this however:A filter is said to be a free filter if the intersection of all of its members is empty. A principal filter is not free. Since the intersection of any finite number of members of a filter is also a member, no filter on a finite set is free, and indeed is the principal filter generated by the common intersection of all of its members. A nonprincipal filter on an infinite set is not necessarily free.
Comment: So some take "free" just to mean the intersection is empty, and "non-principle" to mean not 'generated' by a smallest nonempty set.  Although in another source they are the same.  So frustrating.
Comment: Wow. That's annoying....
Comment: Sadly, that's more common than you might think. I've run into [even worse terminology issues](http://math.stackexchange.com/questions/191588/problem-with-tree-definitions) than that.

Free ultrafilters on $\mathbb N$


Another Riesz-ian Question Regarding Chapter 2 of Rudin's Real and Complex

Question: So as to save space/time, the proof is detailed here: http://data.imf.au.dk/kurser/advanalyse/F06/lecture16-print.pdf
My question is why is it that the measure of compact $K$ (in page 17 of source, third paragraph) is necessarily greater that the functional's value on $f$ ie: $\mu(K)\geq\Lambda(f)$ ?
thank you,
Answer: For any open set $V\subseteq X$,
$$\mu(V):=\sup\{\Lambda(f): f\prec V\},$$
and for any subset $E\subseteq X$,
$$\mu(E):=\inf\{\mu(V): E\subseteq V\}.$$
Let $K$ be a compact set, with $K\subset V$, where $V$ is open. You want to show $\mu(K)\geq \Omega(f)$.
Well, it's a definition chase:
$$\mu(K):=\inf_V\{\sup_f\{\Lambda(f): f\prec V\}\}\geq \inf_V \{\Lambda(f)\}=\Lambda(f)$$
Really we're just using the fact that if $a_n\geq c$ then $\inf_n a_n \geq c$.
Comment: Thanks, I think I understand what you are saying. I will summarize the proof:

For open $V$ there is a real $\alpha$: $ \alpha< \mu(V)$ and there exists a $f$ dominated by V : $\alpha \leq \Lambda(f)$. One can consider an open set $W$ containing the support $K$ of $f$, from which it follows that $\mu(W) \geq \Lambda(f) $ now taking the inf over all such W we have $\mu(K)=\inf(\mu(W): K\subset W, \text{f dom by W})\geq \Lambda(f)$. Whereby the conclusion follows.


Prove $c,c^c,c^{c^c},c^{c^{c^c}},\ldots \pmod p$ with $p$ prime has period $1$ or $2$

Question: Suppose $p$ is a prime number and $c$ is some constant value which is coprime to $p$. I found that $c,c^c,c^{c^c},c^{c^{c^c}},\ldots \bmod p$ have period $1$ or $2$.
In other words, it seems sequence,$(\ ^nc )_{\geq1}$, have period $1$ or $2$.
Can we prove this?
The code which I used is here: link
Comment: Are you specifically taking each $a_j$ to be between $0$ and $p$? If $p=3$ and $c=2$ and $a_0=1$, then the $a_n$ alternate back and forth between $2$ and $1$.
Comment: The limit is simply the solution of the problem $c^x\mod (p)=x$
Comment: I'm sorry. I specifically choose $a_0=c$ in the code. I change the statement of question now.
Comment: In the example Mindlack provides even with $a_{0}=c=3$ we don't have a solution. I see it as a problem of fixed points, you could even reinterpret it as a problem in Group theory by considering then as permutations if you don't want to apply number theory.
Comment: Maybe you could provide the numerical data you were dealing with.
Comment: May I suspect, that you actually work with $c \pmod p$, $c^c \pmod p$,$c^{c^c} \pmod p$ ,$ \cdots \pmod p$ instead? (Note that this formulation against yours gives different results, possibly according better to your proof -intent and I remember to have looked at this in the context of modular tetration sometime ago and might have seen the constant sequence for many examples)
Comment: >Gottfried Helms I'm sorry for confusing. Yes.
Comment: Ah, well, so possibly you better use the notation (known from discussion of tetration) $a_n(c,p)= \,^n c \pmod p \qquad \text{ for } n>0 $ and whether $a_{n+1}(c,p)=a_n(c,p) \qquad \text{for } n \gt n_0$ with some $n_0$
Comment: I check the sequence once again and it's not converge at all. The period is 1 or 2.I add code which I used. https://wandbox.org/permlink/VLWZrrutUiQaL7NV
Comment: ueir - if my previous comment is what really happened then you might also add the tag `tetration`to your question.
Comment: Thank you. I add a tag and change the notation.
Answer: That's false. Consider $c=3$ and $p=7$. Note that $c^2=2$, $c^4=4$ mod $7$. So depending on the value of $a_0$, you can have two constant sequences. Worse: with $a_0=3$, the sequence is a cycle $3,6,1,3,6,1,\ldots$.
Comment: I'm sorry. I specifically choose $a_0=c$ in the code. I change the statement of question now.
Answer: update
If you actually wanted to prove that $ \,^nc \pmod p$ converge to a constant sequence then the following might help for a proof:
assume $p=7$, $c=5$
Then what you ask for is whether $\{5, 5^5 , 5^{5^5}, ...\} \pmod 7$ converge to a constant sequence.
This is a question of recursive application of "order of cyclic subgroup" :

we know $5^k \pmod 7= 5 ^ { k \pmod {\varphi(7)}}\pmod 7= 5 ^ { k \pmod 6}\pmod 7$
Now if $k$ is itself a power of $5$ then we ask furtherly for the residues of $k=5^j \pmod 6$.
we find that this is $5^{j \pmod 2} \pmod 6$
And one step higher this becomes a constant sequence.

Here it is surely meaningful to try a proof. (I think, this should be easy to derive one from that example)

old version   (removed. You can see it in the "edit-history")
Comment: The key fact is $\phi(p),\phi(\phi(p)),\phi(\phi(\phi(p))),\ldots$ is strictly decreasing sequence until it becomes 1. Then, maybe there is some mistake in the code. Thank you.
Comment: [This answer](https://math.stackexchange.com/questions/1159995/do-the-last-digits-of-exponential-towers-really-converge-to-a-fixed-sequence/1160327#1160327) seems to show that the sequence is eventually constant.
Comment: @pregunton - a very nice answer you've found! Perhaps it could be a bit shaped (upps my comment crossed with that last one of ueir)


Keep search results after sort in Ruby on Rails

Question: I am trying to build a sortable AND searchable list.
Both functions work on their own, but when I search and then try to sort the results, I get all elements again and not only the searched ones.
My view looks like below:
<%= form_tag(user_subnets_path, :method => "get", id: "search-form") do %>
  <%= text_field_tag :search, params[:search], placeholder: "Search Subnets" %>
  <%= submit_tag "Search" %>
<% end %>

<% if @subnets.blank? and params[:search]%>

There are no subnets containing the term "<%= params[:search] %>".

<% else %>

      <%= sortable "name" %>
      <%= sortable "CIDR", "CIDR" %>

    <% @subnets.each do |subnet| %>

        <%= subnet.name %>
        <%= subnet.CIDR %>
        <%= link_to 'Show', user_subnet_path(@user, subnet) %>
        <%= link_to 'Edit', edit_user_subnet_path(@user, subnet) %>

    <% end %>

<% end %>

The corresponding controller
...
def index
  #TODO: keep params after submit -> Search + order at once
  @user = User.find(params[:user_id])
  @subnets = @user.subnets.order(sort_column+ ' ' +sort_direction).search(params[:search])
  respond_to do |format|
    format.html
    format.csv { send_data Subnet.to_csv(@subnets) }
  end
end
...

private

def subnet_params
  params.require(:subnet).permit(:name, :CIDR)
end

def sort_column
  if params[:id]
    Device.column_names.include?(params[:sort]) ? params[:sort] : "IP"
  else
    Subnet.column_names.include?(params[:sort]) ? params[:sort] : "name"
  end
end

def sort_direction
  %w[asc desc].include?(params[:direction]) ? params[:direction] : "asc"
end

And the search function from the model
def self.search(search)
  if search
    where("subnets.name LIKE ? OR subnets.CIDR LIKE ?",  "%#{search}%", "%#{search}%")
  else
    all
  end
end

And the application_helper
module ApplicationHelper
  def sortable(column, title = nil)
    title ||= column.titleize
    direction = (column == sort_column && sort_direction == "asc") ? "desc" : "asc"
    link_to title, :sort => column, :direction => direction
  end
end

Is there an easy way to do this?
I am running Rails 5.1.4
Thanks in advance!
Comment: Please post your helper class where from `sortable` come
Comment: I added the `application_helper` code
Comment: Try applying the order method after you call the search method in your index action
Answer: Seems to be ok all are right now just little change to the application helper sortable method and last line
Try to the following
def sortable(column, title = nil)
    title ||= column.titleize
    direction = (column == sort_column && sort_direction == "asc") ? "desc" : "asc"
    link_to title, request.query_parameters.merge({sort: column, direction: direction})
end

Hope it helps


Does the tangent bundle on a 2-sphere span $\mathbb R^3$ and how are the operations defined?

Question: As a follow-up to this question I would like to clarify whether the tangent bundle on a sphere in $\mathbb R^3$ spans $\mathbb R^3$ to make sure I get the concept.
The tangent bundle is the set of the tangent planes at every single point on the surface of the 2-sphere $S$ and would be defined as
$$TS := \{(p, v):\ p\in S, v\in T_pS\}$$
If I get the idea correctly, there would be tangent planes through each point on the surface like the following ones in the drawing representing 3 single points ($P, S, Q)$:

Each plane would be translated to go through the origin to construct a vector space of tangent planes:

If the above is correct, the intuition is clear: the tangent bundle on the sphere would enable us to find a plane in any possible orientation, and hence, the disjoint union of these tangent planes would span $\mathbb R^3.$ Or is the disjoint piece a game changer?
QUESTIONS:

Does this "fan" of translated tangent planes span $\mathbb R^3$?
And how are the addition and scalar multiplication of a vector space defined on this tangent bundle?
Comment: Do you mean span as in span of a subset of $\Bbb R^3$ or just that the union of the tangent planes gives $\Bbb R^3$? The latter is false; just take any plane passing through the sphere. The former is true; consider the 3 tangent planes each containing one of the canonical (standard) basis vectors of $\Bbb R^3$.
Comment: @PrasunBiswas I meant it as in the second idea: would the (disjoint) union of these infinity planes shooting out from zero in all directions "reproduce" $\mathbb R^3$?
Comment: I don't think so. None of the tangent planes contain points that are in the interior of the sphere.
Comment: @Prasun Biswas What about the fact that the planes are translated through the origin?
Comment: Does it matter? Any plane of $\Bbb R^3$ can be seen as a translation of some plane passing through origin.
Answer: The tangent bundle $TS$ of the two dimensional sphere $S$ is the set you mentioned in the question.  I'm not sure in what sense you ask if it spans $\mathbb R^3$ though ($TS$ is not even a subset of $\mathbb R^3$). The tangent bundle does not, in general, have the structure of a vector space. Each tangent space $T_pS$ can be given one, but their disjoint union can't.
The fact that $TS$ is the disjoint union of the $T_pS$ and not simply their union is key. You want to keep track of the point the vectors in the tangent space are tangent to in order to keep vectors coming from different tangent spaces separate. So when you form the tangent bundle you prefix every tangent vector with the point it's tangent to, from which the definition $TS=\{(p, v):\ p\in S, v\in T_pS\}$. Since the manifold you are starting from, $S$, is a $2$-dimensional object, and you are attaching $2$-dimensional objects $T_pS$ at every point $p\in S$, it's reasonable to think that $TS$ should be a $4$-dimensional object. And in fact it is, it's a $4$ dimensional manifold, but not, in general, a $4$-dimensional vector space.
That is generally speaking because, in some cases, like $T\mathbb R^n$, there is the structure of a $2n$ dimensional vector space since $T\mathbb R^n$ is essentially $\mathbb R^n\times \mathbb R^n$, but in general there is no meaningful vector space structure on a tangent bundle.
Note on the disjoint union: the disjoint union is a general construction. If for every element $a$ in a set $A$ you have another set $B_a$ (that may depend on $a$), the disjoint union is
$$
  \biguplus_{a\in A} B_a:=\bigcup_{a\in A} \{a\}\times B_a = \{(a, b):\ a\in A, b\in B_a\}
$$
Comment: You could have, but that doesn't tell you what the "dimension" of the tangent bundle should be. In your drawing tangent spaces of different points on the sphere may intersect, in the tangent bundle they are kept separate. If you want another way of looking at it, to pick a point on the tangent bundle you need to pick a point $p$ on the sphere (2 degrees of freedom) and then you need to pick a vector on the tangent space to $p$ (another 2 degrees of freedom). Total: 4 degrees of freedom to determine a point in $TS$
Comment: @justquestions the dimension of $\Bbb R^3$ is too low to contain the information about the tangent spaces properly. And yes, the tangent planes are vector spaces, and no, the tangent bundle is not a vector space.
Comment: Draw arrows coming out of $p$ in $T_pS$, those arrows are your vectors. The tangent bundle is the union of all the arrows with their originating point from all the tangent planes, so no no vector space structure on the tangent bundle in general, unless you can tell me how you sum points of a sphere and multiply them by a scalar.
Comment: You can also see it this way: you can sum the arrows if they come out of the same point $p$ of the sphere, but an arrow attached to a point $p$ and one attached to another point $q$ have no meaningful sum, since they literally live on different vector spaces.
Comment: Regarding the idea of 4 dimensional manifold, how is it then that if I had an uncountably infinite amount of time I could have drawn all the tangent planes - one for every point, not just 3 exanples - within the confines of a 3D representation of the diagrams in the OP?
Comment: Also, what is the point of translating these planes to the origin if we are not going to get a vector space (identity element)?
Comment: @justquestions well, translating the planes to the origin is actually pointless.
Comment: The identification of $T_pS$ with a plane through the origin of $\mathbb R^3$ just gives $T_pS$ a vector space structure. You could imagine another copy of $\mathbb R^3$ with the origin $0$ at $p$ instead of translating $T_pS$
Comment: So the drawing is wrong? - there is no way for these planes not to intersect...
Comment: So the tangent plane is a vector space, but not the tangent bundle?
Comment: @Fra You closed the loop in your last sentence, because that was precisely my second question in the OP. I couldn't see that, but now it is clearer - the vector space formed by all the vectors tangent to the point is simply a subspace of $\mathbb R^3$ with the usual sum and scalar multiplication. Hence the TS is a vector space, but not the bundle.


Joint distribution of dependent Binomial random variables

Question: Suppose we have $X_{1} \sim B(m,p_{1}), X_{2} \sim B(m,p_{2}),\cdots, X_{n} \sim B(m,p_{n})$ and they are dependent. Does the joint distribution $f(X_{1},X_{2},\cdots,X_{n}) $ have a closed form?
Edit: let's take as an example a random graph, what's the joint distribution of the degrees of an ER random graph?
Comment: Something more than 'they are dependent' needs to be assumed for the joint distribution to even be uniquely defined.
Comment: Or perhaps it's better to post a new question since this already has an answer that's getting upvotes.
Comment: If that's what you are interested in, could you perhaps make the question to be about whether the joint distribution of the degrees of an Erdős–Rényi (I presume) graph is available in closed form? (I don't think there can be any general answer).
Answer: There is no unique joint distribution. In fact, there are infinite possibilities to construct the joint distribution. For instance, there exist infinitely many copula functions that can be used to construct a joint distributions with such marginals.
Comment: +1 But note that many of those copulae produce the same joint distribution.  It might be clearer to appeal to the discreteness of this distribution: when $n\ge 2$, it is determined by $(m+1)^n$ numbers (all in the interval $[0,1]$) subject to $n m + 1$ independent linear constraints (to match the marginal distributions and to sum to unity).  That means $f$ has $(m+1)^n-(nm+1)$ free parameters.