erro T_NS_SEPARATOR

[Yuri Pereira Ramos 0]

boa tarde galera estou recebendo o seguinte erro no meu código php:Parse error: syntax error, unexpected T_NS_SEPARATOR in C:\xampp\htdocs\capgov\painel2\loadPDF.php on line 101



Segue a linha 101: $object[$dir]['scrum'] ="<IFRAME src="Jit\Examples\Treemap\example1.html" width=\"250"\ height=\"350'"\ scrolling=\"no"\ frameborder=\"0"\ align=\"center"\> </IFRAME>";


aonde está o erro galera? sei que tem algo a ver com as barras mas já mudei elas de posição mil vezes e nao resolvo!


obrigado

[Alaerte Gabriel 662]

Dê uma lida sobre erros comuns, e sobre tratamento de erros.

 

 

Considere ler:

 

 

:seta: http://forum.imasters.com.br/topic/375491-erros-comuns-com-php/

 

:seta: http://forum.imasters.com.br/topic/229485-tratamento-de-erros/

[cristianoolv 93]

o erro aki

Jit\Examples\Treemap\example1.html

 

e outro aki

height=\"350'"\

[Alaerte Gabriel 662]

Pronto... viu como é simples Yuri Pereira Ramos ? Só saber o que os erros dizem e prestar bem atenção no que está fazemdo, leia os links que passei e saberá.

[mangakah 217]

T_NS_SEPARATOR é o caractere '\'. Esse é um caractere especial que é usado tanto para escapar caracteres especiais (inclusive ele mesmo) quanto para separar Namespaces (NS).

 

Se a sua string não tem nenhuma variável PHP inserida nela, mas tem código HTML e consequentemente aspas duplas, melhor delimitá-la usando aspas simples e usar '/' no lugar de '\':

 

$object[$dir]['scrum'] = '<IFRAME src="Jit/Examples/Treemap/example1.html" width="250" height="350" scrolling="no" frameborder="0" align="center"></IFRAME>';

 

Observe que há uma diferença quando se delimita uma string usando aspas simples e aspas duplas. Com aspas duplas variáveis inseridas dentro da string são substituídas pelo seu valor, já com aspas simples, tudo na string é literal.

[Alaerte Gabriel 662]

Isso. Sem contar que existe um ganho na performance, visando que o php não irá a procura de variáveis, por estar delimitado com apóstrofos.

[Evandro Oliveira 331]

...existe um ganho na performance...

Mito. Mas não vamos sair do escopo do tópico.

[Alaerte Gabriel 662]

Mito. Mas não vamos sair do escopo do tópico.

 

Já saiu do escopo. Agora vamos nessa.

 

Existe um ganho "pequeno" na utilização dos apóstrofos. Pois o interpretador quando percorre aspas duplas, ele procura por variáveis dentro delas, para então executar o comando. Quando utilizamos aspas simples, ele por si só entende que não existe variável, então o comando é executado sem a busca por variáveis, é quase que insignificante o ganho de tempo na execução, já fiz alguns testes e constatei.

 

Agora, me convença de que é um MITO, pode estar rolando algo que eu não saiba. :)

[Evandro Oliveira 331]

 

Já saiu do escopo. Agora vamos nessa.

 

Existe um ganho "pequeno" na utilização dos apóstrofos. Pois o interpretador quando percorre aspas duplas, ele procura por variáveis dentro delas, para então executar o comando. Quando utilizamos aspas simples, ele por si só entende que não existe variável, então o comando é executado sem a busca por variáveis, é quase que insignificante o ganho de tempo na execução, já fiz alguns testes e constatei.

 

Agora, me convença de que é um MITO, pode estar rolando algo que eu não saiba. :)

http://codepad.viper-7.com/HVXF19

 

Execute diversas vezes. As linhas são em ordem

aspa única
aspa dupla
aspa única
aspa dupla

Os resultados variam muito entre o vencedor. Vezes eu tive a aspa única, mas vezes eu tive a aspa dupla...

 

 

0.000705 - 'única'
0.000619 - 'dupla'
0.000626 - 'única'
0.000591 - 'dupla'

 

 

http://www.tuxradar.com/practicalphp/18/1/23

 

Lembro de ter lido um artigo que cita, inclusive, a definição do espaço das strings em memória.

 

Edit: Achei! É esse: http://nikic.github.io/2012/01/09/Disproving-the-Single-Quotes-Performance-Myth.html

 

Inclusive, tem complemento... http://www.codeforest.net/php-myth-busters-using-single-quotes-on-string-is-faster-then-double-quotes

 

Boa leitura.

[Alaerte Gabriel 662]

Já havia lido um dos links passados certa vez... Não me convenceu, ainda que insignificante, prefiro utilizar o apóstrofo para str. :thumbsup:

[mangakah 217]

Sério? Vocês estão discutindo por conta de uma diferença menor que míseros 0.000100 segundo. <_<

 

Isso é 1 segundo dividido por dez mil, gente. Pelamor!

[Bruno Augusto 417]

manga, nesse caso foi 0.000100 pois foi usada uma única string sobre um grande número de iterações.

 

As micro-otimizações são chatas? Sim, são. Nem sempre devem ser feitas? Sim, de fato. É custoso do ponto de vista da relação custo-benefício? Sim, é.

 

Mas eu sou da opinião que se pode fazê-lo, faça. Uma string não faz diferença, mas uma aplicação não é feita de uma única string.

 

Se é sabido que há uma variação entre uma função e outra, vale a pena estudar uma alternativa. Se é conhecido que concatenar strings em aspas simples e as variáveis envolvidas é mais eficiente do que colocar tudo entre aspas duplas, por que não fazer?

[Alaerte Gabriel 662]

:assobiando: +1

 

Uma string não faz diferença, mas uma aplicação não é feita de uma única string.

[Evandro Oliveira 331]

Sério? Vocês estão discutindo por conta de uma diferença menor que míseros 0.000100 segundo. <_<

 

Isso é 1 segundo dividido por dez mil, gente. Pelamor!

A minha implicância é quanto à transmissão de informação incorreta/equivocada:

[...] Sem contar que existe um ganho na performance [...]

No caso do nosso colega, não existe. Ele pediu provas e eu provei. Não estou questionando que concatenação é mais rápida que interpolação. Rebati apenas um conselho equivocado.

 

Mais à frente, temos:

Já havia lido um dos links passados certa vez... Não me convenceu, ainda que insignificante, prefiro utilizar o apóstrofo para str. :thumbsup:

Agora passou a ser questão de preferência. Ponto. Fim de papo e eu não discuti mais. Ele poderia ter rebatido, também, que acha mais bonito, mais cômodo, que o apóstrofo no teclado dele fica mais acessível dentre N outras justificativas e, enquanto válidas, seriam prontamente aceitas. "ganho de performance, ainda que pequeno" é inválido quando tratamos de strings simples - caso do tópico.

 

 

 

@Bruno Augusto, você sabe o quanto eu sou chato no tocante sobre destoar o assunto inicial do tópico. Mas, infelizmente, isso já aconteceu, então...

Se é conhecido que concatenar strings em aspas simples e as variáveis envolvidas é mais eficiente do que colocar tudo entre aspas duplas, por que não fazer?

Porque a linguagem de programação foi criada para humanos. Seguindo sua linha de raciocínio, uma quebra de linha desnecessária não interfere na performance, mas e um sistema inteiro??

 

Os comentários de uma função são ignorados com impacto quase mínimo. Mas e numa lib inteira? E num framework? Bom, porque não fazer, né?

function ($arg1=null,$arg2=null,$arg3=null){$args=func_get_args();echo 'recebi '.count($args).' argumentos<br>São eles:';foreach($args as $arg)echo' '.$arg.'<br>';}

Super otimizada na questão de performance. Mas eu pergunto: vale a pena? Não compensa mais utilizar um sistema de caching?

 

Veja quantas outras coisas nós não fazemos que são muito mais danosas pra performance do que tratamento de strings. Coisas como autoloaders, um arquivo por classe, arquivos de configuração separados. Arquitetura de desenvolvimento em camadas. Acesso ao disco está entre os maiores vilões da performance dum sistema.

 

Prova disso? Google armazena o máximo possível em

.

 

Voltando às strings, quando concatenamos/interpolamos variáveis, a ordem de performance fica assim: Aspa única > Aspas duplas (concatenação) > Aspas duplas (iterpolação delimitada) > Aspas duplas (interpolação não-delimitada) > *print(f)

 

A diferença entre interpolação delimitada e não-delimitada é essa:

echo "interpolação {$delimitada}" . "interpolação não-$delimitada"

Nunca fiz testes nem encontrei literatura que compare HEREDOC ou NOWDOC com aspas duplas. Mas, por se comportarem de igual forma, acredito que sejam bem similares.

 

Vejam que as funções da família print ficam por último. Mas me digam se não é uma coisa linda de se fazer:

<?php

// Troca pt-BR por pt_BR
$langs = str_replace('-', '_', $_SERVER['Accept-Language']);

// Adiciona o inglês americano como última alternativa
$langs .= ';en_US';

$langs = explode(';', $langs);

// Remove as informações de prioridade (q=0.8)
$langs = array_filter($langs, function ($lang) { return false === strpos($lang, '='); });

setlocale(LC_ALL, $langs);

bindtextdomain('forum-imasters', 'app/locales');
textdomain('forum-imasters');

$name = 'Evandro';

echo sprintf(gettext('greetings'), $name);

pt_BR.po

"Language: Português do Brasil"
msgid "greetings"
msgstr "Olá, %s"

en_US.po

"Language: Inglês americano"
msgid "greetings"
msgstr "Hello, %s"

Agora, quero ver quem vai vir falar pra fazer com [inline]str_replace[/inline] porquê [inline]sprintf[/inline] é lento...

[Bruno Augusto 417]

Evandro, pareceu que minha resposta foi uma crítica ao seu ponto de vista? Sinceramente não foi essa minha intenção.

 

Muito pelo contrário, estou concordando em gênero, número e grau contigo. :thumbsup:

 

Dentre as micro-otimizações, acho que a única que não sigo (e podem me socar de porrada que eu não vou seguir) é parar de interpolar strings e variáveis através de (v)(s)printf.

[Enrico Pereira 299]

Nós estamos falando de PHP, não estamos falando de um reator nuclear, de um sistema embarcado ou de outra coisa em que performance é algo crítico.

 

Não precisamos estragar ou somente piorar um pouquinho que seja para ganhar performance, a não ser que seja realmente necessário.

 

Banco de dados, acesso à webservices, acesso à arquivos em disco, parte do front-end (html, css, javascript e imagens), e etc. são muitas coisas que devemos otimizar (na maioria dos casos usando cache) e às vezes não fazemos, e depois vamos usar c ao invés de cheque no nome da variável para deixar o arquivo com tamanho mais leve. Isso é comum e destrói qualquer sistema, você chega a garantir seu emprego de forma vitalícia porque ninguém mais sabe dar manutenção naquele código (sarcasmo...).

 

É muito fácil criar um código para a máquina ler, qualquer idiota consegue, mas o código é feito para humanos, como já diria ^{_{o guru-vovô-que-não-programa-em-PHP}} Martin Fowler.

 

 

Veja quantas outras coisas nós não fazemos que são muito mais danosas pra performance do que tratamento de strings. Coisas como autoloaders, um arquivo por classe, arquivos de configuração separados. Arquitetura de desenvolvimento em camadas.

 

Mas são boas práticas... não podemos abdicar de um bom código. Autoloaders/arquivos de classe podemos, no final do projeto, juntar tudo em um arquivo só.

 

Podemos sim otimizar, quando faz sentido, não simplesmente sair abreviando tudo, tirando espaços, etc.

 

O que vale é o bom código, a performance se consegue de outras formas. E mais importante que performance (digo, rapidez de carregamento) é consumo de memória (apesar de ser relacionado à performance).

[Alaerte Gabriel 662]

#16

 

Concordo plenamente. Um bom código, limpo, que da "gosto" de se olhar. Minha intenção é, se você vai echoar ou printar partes que contenham só string, porque não utilizar o apóstrofo, que reconhece o que se tem como string ? né ? Acredito que tudo isso vá contando, e no final das contas existe um ganho na organização, facilidade de entendimento, e se a união faz a força porque não dizer performance ?

 

 

Uma string não faz diferença, mas uma aplicação não é feita de uma única string.

 

Me refiro ao conjunto utilizado, me refiro a soma das boas práticas de programação e não a um caso específico de um print ou um print em uma string.

 

#14

No caso do nosso colega, não existe. Ele pediu provas e eu provei. Não estou questionando que concatenação é mais rápida que interpolação. Rebati apenas um conselho equivocado.

 

Não, eu não estou equivocado, se eu disse é porque eu já havia feito testes antes e obtive micro resultado favorecendo o apóstrofo e não a aspa dupla, o negócio é dar a césar o que é de césar, se é string seca, pura, então trate-a de tal forma, isso se chama caminho limpo.