🤑 15% de desconto na Alura → tidd.ly/4df0vz7 🪄 Post sobre métodos mágicos → dias.dev/2023-08-11-metodos-magicos-php/ 📊 Post sobre economia de recursos do PHP → dias.dev/2024-04-18-copy-on-write-php/ E se quiser apoiar o canal e me incentivar a continuar criando conteúdo gratuito, você pode considerar me dar um "Valeu Demais" aqui no RUclips ou se tornar um "sponsor" lá no GitHub: github.com/sponsors/CViniciusSDias
estou estundando C# depois de aprender PHP, é legal de ver a semelhança entre as duas linguagens. Com certeza saber o PHP antes me ajudou a me familiarizar mais rápido com o C#.
Muito bom saber que a comunidade pega inspiração de outras linguagens, no caso, C#. Melhor pra mim que as duas linguagens que eu trabalho estão ficando cada vez mais parecidas
Conheci isso no C# e achava maravilhoso! É muito bom ver o PHP evoluindo tanto. Na lista internals vejo ótimas discussões, pena que algumas esbarram em muitos problemas técnicos pra avançar.
Bem Interessante, eu já usei libs do spatie pra fazer esse tipo de coisa, pega o primeiro e ultimo nome e a propriedade automaticamente pega os dois e une. Muito bom!
Meu sentimento com essa RFC é que estão "complicando" o que era fácil. Imagina você avaliando um PR de um júnior e declinar devido o código ter um possível overflow de memória (caso dos arrays de 1 milhão de usuários dito no vídeo por exemplo), e ele te perguntar "mas por quê terá overflow ?", e você ter que explicar o uso/acesso da memória. Vou indicar logo o link desse vídeo no PR hahaha Abraços Vinicius, parabéns pelo vídeo!
Então, existe sim uma complexidade adicionada. Nesse ponto concordo com você. Mas esse problema de overflow não existe porque a funcionalidade já não permite que essa cópia seja feita, então é seguro. :-) Agora se precisar explicar sobre esse uso de memória pra um Jr., melhor mandar esse texto aqui, ao invés do vídeo heheheh: dias.dev/2024-04-18-copy-on-write-php/
Acho interessante essas novidades, mas eu, que sou das antigas, nao curti muito não rsrs Acho que utilizando os métodos tradicionais, embora escreva mais código, fica mais claro, explícito.... Nas essa é somente a minha humilde opinião, e acho bacana que a linguagem evolua, sempre!
Eu também achei bem estranho de início. E também gosto de código mais explícito, com menos mágicas. Embora eu tenha me habituado com a sintaxe depois de tanto ler, também não sei se vou usar tanto. rsrsrs
Acho que a maioria dos devs php ja pensou nisso e implementou de alguma forma, metodos get/set burros são a primeira coisa que um dev tenta contornar! Os frameworks ja fazer isso a um tempo através dos mutators e accessors, ver o php trazer isso nativo me deixa muito feliz!
Pra ficar claro: definir propriedades somente com o hook get (como no exemplo do fullName), sem acessar ela própria dentro do hook com "$this->fullName", deixa a propriedade readonly e tentar definir algum valor a ela obviamente gera um erro (mesmo que a propriedade seja pública). Isso é uma forma de definir "propriedades metadados", que são basicamente propriedades geradas a partir de outras prioridades (e/ou dados externos), o que é muito legal!
Bela apresentação do conteúdo. Em um primeiro momento não vi nenhuma vantagem em relação aos métodos magicos __get e __set. Já era possivel fazer coisas como: public function __get($prop) { $method = 'get' . ucfirst($prop); If (method_exists($this, $method)) { return $this->$method(); } return $this->$prop; } Vinícius o que muda na prática em relação ao exemplo acima e essa nova rfc?
A definição de cada "get" fica mais explícita. Mas esse código aí é exatamente o que eu costumava fazer em traits quando queria essa funcionalidade de property hooks. rsrsrs Geralmente, mudanças de sintaxe não trazem funcionalidade nova. Elas trazem novas formas de fazer algo que já era possível. O mesmo serve para match expression, constructor property promotion e várias novidades maneiras que têm chegado.
É suportado, como eu disse no vídeo e como dá pra ver no link. :-) Mas geralmente, novas sintaxes são exatamente isso: uma forma diferente de fazer a mesma coisa
Acho essas paradinhas sempre maneiras, mas o que eu sinto falta no PHP de verdade é a sobrecarga de operadores que ajuda pra caramba em meta programação deixando o código muito mais intuitivo, principalmente quando deixamos de utilizar tipos escalares e queremos representar os valores de outra forma como um decimal por exemplo. Recurso esse conheci no c++ e depois vi implementado também no ruby.
@@DiasDeDevPois então, se já tem para algumas, libera pra geral kkkkkkk. Bizarrices já são feitas com os recursos que existem hoje, então um a mais ou a menos não vai fazer diferença..
Criar websockets com PHP é possível, sim. Já até tem vídeo aqui no canal. Reconhecimento de voz eu nunca pesquisei, mas imagino que exista algo sim, principalmente com FFI.
@DiasDeDev, como que ficaria a questão do encapsulamento ? Pois nesse caso as propriedades se tornam publicas, meio que perdendo o sentido de encapsular as propriedades. Eu não entendi muito bem essa parte. Com as properties hooks o PHP encapsula as propriedades automaticamente ? Isso não ficou muito claro para mim.
> Isso seria um encapsulamento certo? Não. Isso não é encapsulamento. Encapsulamento é um conceito, uma ideia da orientação a objetos, onde você expõe ao mundo externo somente o que é necessário. dias.dev/2020-04-13-programacao-procedural-orientada-a-classes-parte-1/
De forma bem resumida, pode ver dessa forma sim. Ainda tem as propriedades virtuais e os detalhes mais aprofundados (tipo propriedades em interfaces, etc).
Lombok não é da linguagem. É um projeto externo e extremamente criticado por todas as pessoa que trabalham com Java e falam sobre boas práticas que eu conheço. rsrsrs Acho que prefiro mil vezes essa abordagem na pegada de C#, Kotlin e companhia. Lombok é exemplo a não seguir. rsrsrs
@@DiasDeDev me referir as Annotation. Porq se for para pra pensar, se for pra nao declarar gatter e setter faz muito mais sentido usar Annotation da forma do lombok uai. e tipo se for pra acessar a variável, direto como atributo e nao declarar method fica estranho tbm. mas entendo seu ponto de vista.
Ao definir SET para propriedade $foo omitindo parâmetro, creio que seria mais lógico utilizar $foo (nome da propriedade) invés de $value no exemplo que citou acima, entendo que é o padrão do PHP 8.4 ser $value mas... não me agrada.
![Novidades do PHP 8.4 - Atributo #[Deprecated] | Dias de Dev](http://i.ytimg.com/vi/gP9K5l_qxIY/mqdefault.jpg)
![Novidades do PHP 8.4 - Atributo #[Deprecated] | Dias de Dev](/img/tr.png)
🤑 15% de desconto na Alura → tidd.ly/4df0vz7
🪄 Post sobre métodos mágicos → dias.dev/2023-08-11-metodos-magicos-php/
📊 Post sobre economia de recursos do PHP → dias.dev/2024-04-18-copy-on-write-php/
E se quiser apoiar o canal e me incentivar a continuar criando conteúdo gratuito, você pode considerar me dar um "Valeu Demais" aqui no RUclips ou se tornar um "sponsor" lá no GitHub:
github.com/sponsors/CViniciusSDias
Conteúdo muito rico. Parabéns pelo vídeo!
estou estundando C# depois de aprender PHP, é legal de ver a semelhança entre as duas linguagens. Com certeza saber o PHP antes me ajudou a me familiarizar mais rápido com o C#.
Sem dúvida ajuda muito!
qualquer linguagem com sintaxi parecida com C/C++ será facil de aprender qnd vc aprende uma delas. São todas parecidas, basta ler a doc
Muito interessante o vídeo!! Essas novidades vão ajudar muito e já até visualizei situações onde seriam indispensáveis.
Legal, né!?
Seu conteúdo e sua didática são sempre incríveis! ❤
Muito obrigado pelo apoio!
Muito bom saber que a comunidade pega inspiração de outras linguagens, no caso, C#. Melhor pra mim que as duas linguagens que eu trabalho estão ficando cada vez mais parecidas
Sim. Muito legal ver a evolução.
Muito bom , demorou mas chegou.
heheheh
Conheci isso no C# e achava maravilhoso! É muito bom ver o PHP evoluindo tanto. Na lista internals vejo ótimas discussões, pena que algumas esbarram em muitos problemas técnicos pra avançar.
Sim! C# foi uma das inspirações pra essa RFC
Bom d+, man. Obrigado!
Valeu! Que bom que gostou
Bem Interessante, eu já usei libs do spatie pra fazer esse tipo de coisa, pega o primeiro e ultimo nome e a propriedade automaticamente pega os dois e une. Muito bom!
Sim, as libs usam os métodos mágicos. Eu costumava construir uma trait pra isso.
yep
😁
Meu sentimento com essa RFC é que estão "complicando" o que era fácil.
Imagina você avaliando um PR de um júnior e declinar devido o código ter um possível overflow de memória (caso dos arrays de 1 milhão de usuários dito no vídeo por exemplo), e ele te perguntar "mas por quê terá overflow ?", e você ter que explicar o uso/acesso da memória.
Vou indicar logo o link desse vídeo no PR hahaha
Abraços Vinicius, parabéns pelo vídeo!
Então, existe sim uma complexidade adicionada. Nesse ponto concordo com você.
Mas esse problema de overflow não existe porque a funcionalidade já não permite que essa cópia seja feita, então é seguro. :-)
Agora se precisar explicar sobre esse uso de memória pra um Jr., melhor mandar esse texto aqui, ao invés do vídeo heheheh:
dias.dev/2024-04-18-copy-on-write-php/
@DiasDeDev tu é o cara! Obrigado 🥳
Muito top
Que bom que gostou
Acho interessante essas novidades, mas eu, que sou das antigas, nao curti muito não rsrs Acho que utilizando os métodos tradicionais, embora escreva mais código, fica mais claro, explícito.... Nas essa é somente a minha humilde opinião, e acho bacana que a linguagem evolua, sempre!
Eu também achei bem estranho de início. E também gosto de código mais explícito, com menos mágicas.
Embora eu tenha me habituado com a sintaxe depois de tanto ler, também não sei se vou usar tanto. rsrsrs
Acho que a maioria dos devs php ja pensou nisso e implementou de alguma forma, metodos get/set burros são a primeira coisa que um dev tenta contornar! Os frameworks ja fazer isso a um tempo através dos mutators e accessors, ver o php trazer isso nativo me deixa muito feliz!
Exatamente!
Pra ficar claro: definir propriedades somente com o hook get (como no exemplo do fullName), sem acessar ela própria dentro do hook com "$this->fullName", deixa a propriedade readonly e tentar definir algum valor a ela obviamente gera um erro (mesmo que a propriedade seja pública).
Isso é uma forma de definir "propriedades metadados", que são basicamente propriedades geradas a partir de outras prioridades (e/ou dados externos), o que é muito legal!
Isso aí! :-D
No PHP elas serão chamadas de virtual properties (propriedades virtuais).
carai, ainda bem que vi esse video, imagina daqui algum tempo se eu vejo um codigo deste sem saber isso , vou pensar que o código ta errado
Heheheh
Essa problema do array poderia ser resolvido futuramente com um hook chamado "push" para ser usado somente em arrays. Acho q seria um solução.
Existem outros hooks no escopo futuro da RFC sim. Vamos ver o que o futuro nos reserva. hehehe
Bela apresentação do conteúdo.
Em um primeiro momento não vi nenhuma vantagem em relação aos métodos magicos __get e __set.
Já era possivel fazer coisas como:
public function __get($prop) {
$method = 'get' . ucfirst($prop);
If (method_exists($this, $method)) {
return $this->$method();
}
return $this->$prop;
}
Vinícius o que muda na prática em relação ao exemplo acima e essa nova rfc?
A definição de cada "get" fica mais explícita. Mas esse código aí é exatamente o que eu costumava fazer em traits quando queria essa funcionalidade de property hooks. rsrsrs
Geralmente, mudanças de sintaxe não trazem funcionalidade nova. Elas trazem novas formas de fazer algo que já era possível.
O mesmo serve para match expression, constructor property promotion e várias novidades maneiras que têm chegado.
Se for suportado em interfaces e classes abstratas é útil, senão é só uma forma diferente de fazer a mesma coisa
É suportado, como eu disse no vídeo e como dá pra ver no link. :-)
Mas geralmente, novas sintaxes são exatamente isso: uma forma diferente de fazer a mesma coisa
salve carlão
Opa!
@@DiasDeDev vem para o japao carlao!
Bora conhecer tecnologia aqui!
Meio longe, né!? heheheh
Acho essas paradinhas sempre maneiras, mas o que eu sinto falta no PHP de verdade é a sobrecarga de operadores que ajuda pra caramba em meta programação deixando o código muito mais intuitivo, principalmente quando deixamos de utilizar tipos escalares e queremos representar os valores de outra forma como um decimal por exemplo. Recurso esse conheci no c++ e depois vi implementado também no ruby.
Eu já fico meio receoso de ter esse recurso justamente pelo fato de ter sido tão mal utilizado em C++ (vide std::cout
@@DiasDeDevPois então, se já tem para algumas, libera pra geral kkkkkkk.
Bizarrices já são feitas com os recursos que existem hoje, então um a mais ou a menos não vai fazer diferença..
Já usou alguma bibliotecas de php para reconhecimento de voz, pode mp3 para texto?
Php websock é possível?
Criar websockets com PHP é possível, sim. Já até tem vídeo aqui no canal.
Reconhecimento de voz eu nunca pesquisei, mas imagino que exista algo sim, principalmente com FFI.
@DiasDeDev, como que ficaria a questão do encapsulamento ?
Pois nesse caso as propriedades se tornam publicas, meio que perdendo o sentido de encapsular as propriedades.
Eu não entendi muito bem essa parte. Com as properties hooks o PHP encapsula as propriedades automaticamente ?
Isso não ficou muito claro para mim.
Acho que você tá confuso no termo "encapsulamento". O que você quis dizer em termos práticos?
@@DiasDeDev por exemplo, você tem um seguinte código:
> Isso seria um encapsulamento certo?
Não. Isso não é encapsulamento.
Encapsulamento é um conceito, uma ideia da orientação a objetos, onde você expõe ao mundo externo somente o que é necessário.
dias.dev/2020-04-13-programacao-procedural-orientada-a-classes-parte-1/
@@DiasDeDev , Obrigado! Agora ficou mais claro hehe, vou dar uma olhada no seu artigo. Sucesso Brother! Você tem uma excelente didática.
PHP# kkkk
é quase um construtor? funciona de maneira global?
É igual aos métodos __get e __set. Não entendi o que você quis dizer com "global".
@@DiasDeDev como para trafegar e definir posteriormente por exemplo
Continuo não entendendo. Consegue colocar um exemplo?
Acho que a única mudança é que vai ter um __set e __get para cada variável de forma individual.
Foi o que eu entendi de forma resumida..
De forma bem resumida, pode ver dessa forma sim. Ainda tem as propriedades virtuais e os detalhes mais aprofundados (tipo propriedades em interfaces, etc).
Então:
Tenho que atualizar um programa desenvolvido desde 2007, com registro válido no INPI.
Linguagem PHP.
Procuro parcerias.
Up
eu tenho disposição
Achei bem feito isso. Hahahaaha era melhor ter feito como tem no Java o lombok
Lombok não é da linguagem. É um projeto externo e extremamente criticado por todas as pessoa que trabalham com Java e falam sobre boas práticas que eu conheço. rsrsrs
Acho que prefiro mil vezes essa abordagem na pegada de C#, Kotlin e companhia. Lombok é exemplo a não seguir. rsrsrs
@@DiasDeDev me referir as Annotation. Porq se for para pra pensar, se for pra nao declarar gatter e setter faz muito mais sentido usar Annotation da forma do lombok uai.
e tipo se for pra acessar a variável, direto como atributo e nao declarar method fica estranho tbm.
mas entendo seu ponto de vista.
Sinceramente, não gostei muito dessa RFC, acho que deixa o código mais hierárquico e menos organizado
fica meio estranho realmente
Eu torci o nariz nas 3 primeiras vezes que li também. Agora confesso que tô começando a me acostumar.
Mas entendo perfeitamente seu ponto de vista.
Ao definir SET para propriedade $foo omitindo parâmetro, creio que seria mais lógico utilizar $foo (nome da propriedade) invés de $value no exemplo que citou acima, entendo que é o padrão do PHP 8.4 ser $value mas... não me agrada.
Teve essa discussão na RFC.
copiaram do Swift
A RFC cita várias outras linguagens usadas como inspiração
Sintaxe horrorosa... Mancada dos desenvolvedores do PHP, que poderiam se inspirar em outras linguagens que fazem o mesmo de forma muito mais simples.
Tá escrito na RFC todas as linguagens nas quais se inspiraram, e a sintaxe tá extremamente similar.
Chegou a ler a RFC?
Mais simples e natural que isso seria como?
A parte do array parece gambiarra 😢
Como assim? Criar um método novo é gambiarra? rsrsrs
Não entendi.
isso tem no c# faz tempo kk
Sim, a RFC cita C#, assim como outras linguagens.