On Mon, 16 Jul 2001, [EMAIL PROTECTED] wrote:
>
> Tava eu feliz da vida, fazendo um script Perl (t� certo agora, seu
> chato? ;-) ) que procurava sufixos em taxonomias. Procurar prefixos
�h�. Certinho. :o)
> � mais f�cil que procurar sufixos, ent�o fiz um scriptiznho que
> invertia todas as palavras de um pipe (admito : abrir pipes para
> escrita ou entrada no Perl como se fossem simples arquivos � o
> m�ximo!!!). Pascaleiro como sou, n�o tive d�vidas. Fun��o.
N�o vem ao caso... mas n�o era mais f�cil voc� procurar a seq��ncia
direta no final da string? m/sufixo$/, por exemplo.
> Mas sabemos que em Perl n�o existem par�metros formais, eles v�m em
> um array chamado $_. Perfeito. Mas o identificador $_ tbm � usado na
Isso depende.
O array � @_... Mas, voc� pode, e na verdade deve, criar algo assim:
sub fun��o($parametro1, $parametro2); # Declara��o da fun��o e
# quantidade de vari�veis
...
sub funcao($parametro1, $parametro2) {
my ($parametro1, $parametro2) = @_;
...
}
A primeira declara��o diz quais as vari�veis ser�o usadas pela fun��o,
a segunda inicia a fun��o e a terceira faz a atribui��o das
vari�veis. Na verdade, s� � necess�ria a terceira, mas as duas
anteriores refor�am e ajudam em algumas checagens e otimiza��es do
compilador.
> vari�vel string default em entrada de dados para algumas fun��es
> (como ler um arquivo ou aplicar regex sem especificar
> vari�vel). Como Perl possui um name space para cada tipo de
> vari�vel, perdi 2 horas procurando erro de l�gica que n�o existia
> porque na sub eu tinha colocado my $word = $_ ao inv�s de
> $_[0]. Porque $_ � uma coisa, $_[0] � outra completamente
> diferente...
:-)
O erro n�o foi colocar uma string ($_) ao inv�s de um elemento do
array ($_[0]). O erro foi usar essas vari�veis. Voc� deve, ao m�ximo,
evitar usar isso. Mas a lista n�o � sobre programa��o... ;) Podemos
falar disso na prog-br se desejares
(http://listas.conectiva.com.br/listas/prog-br)
> Isto pra n�o dizer que @array e $array s�o diferentes, mas $array[1]
> � o segundo elemento de @array. E $hash{1} � o elemento "1" de
> %hash, que n�o tem nada a ver com @hash...
:-) Mas essa � a sintaxe da linguagem.
> (Sigh). Se eu me especializar em Perl, com certeza um dia isto deixa
> de ser problema. Mas como f�nz�o de Niklaus Wirth, este tipo de
> coisa d� curto na minha cuca...
Quem?
>> Flamewar! :-)))
>
> YESSSS!!!!!!!!!!!!!! 8-) Let's party!!!!!!!!! 8-)
N�o nessa lista, please. O assunto j� fica MUITO fora de escopo para
ela.
> Al�m do mais Java possui um suporte da ind�stria e dos usu�rios
> maior que Perl, PHP ou Python. Pelo menos, escrevo appletzinhas Java
> de anima��o desde 1992 ou 3 (com java 1.0), antes mesmo deste
> neg�cio de flash e shockwave aparecer (e que por sinal, � mais
> fechado ainda que o Java).
Ser� mesmo??? N�o sei se o suporte dos usu�rios � t�o grande
assim. Mas, tamb�m, nunca fui muito atr�s.
> [ Resumo: Eu afirmo que dar manuten��o em Perl sucks. Godoy afirma o
> contr�rio. Fa�am suas apostas!! ;-)
> ]
Na prog-br, OK??? :-)))
> A m�quina virtual ineficiente em Linux � um problema. Mas pelo
> conte�do das mensagens sobre o kernel do Linux aqui n�o � culpa da
> Sun. Ali�s, as demais JVM aparentemente n�o possuem este problema,
> logo....
Logo, se voc� apostar em Java no Linux, ter� que se contentar com isso
pois em todo esse tempo de exist�ncia, a m�quina ainda apresenta
problemas. E mais! Voc� n�o ter� o c�digo para tentar otimizar o que
voc� precisa da m�quina. Ter� que abaixar a cabe�a e aceitar essas
limita��es.
> O c�digo propriet�rio � um problema sim. E um problema
> grave. Existem iniciativas neste sentido (como o pessoal da Japhar,
> Kaffe, KissMe, ou da blackdown.org), que podem amenizar o
Todos dependem de c�digo propriet�rio da Sun.
> problema. O controle f�rreo da linguagem que a Sun vem exercendo �
> um problema maior, IMHO. Mas aparentemente � a estrat�gia deles para
> evitar que a Microsoft passe a m�o em sua tecnologia sem mais nem
> menos.
Acho que � mais para ganhar $$$ do que qualquer coisa...
> Se a Conectiva consegue fazer dinheiro com Linux, n�o tenho a menor
> d�via que a Sun continuaria fazendo dinheiro com uma vers�o aberta
> do Java. Faria bem menos, sem d�vida. Mas n�o far� nenhum se perder
> a parada pro C# da .NET .
O modelo de neg�cios � diferente.
> Sob esta mesma �tica, a migra��o para o Linux � estremamente
> dif�cil. E o �. Mas vem acontecendo. Se valer a pena, o pessoal
> migra. O Linux v�m provando isto.
Muitas vezes, dependendo da aplica��o, nenhuma altera��o em c�digo �
necess�rio (Cobol, XBase, etc.). Isso incentiva.
Os servidores, tamb�m, em empresas maiores, sempre estiveram em
m�quinas rodando SOs que aguentem situa��es mais cr�ticas.
--
Godoy. <[EMAIL PROTECTED]>
Desenvolvimento de Solu��es -- Solutions Development
Conectiva S.A - www.conectiva.com.br - +55 (41) 360-2600
Conectiva Inc. - www.conectiva.com - +55 (41) 360-2600
Assinantes em 16/07/2001: 2248
Mensagens recebidas desde 07/01/1999: 123127
Historico e [des]cadastramento: http://linux-br.conectiva.com.br
Assuntos administrativos e problemas com a lista:
mailto:[EMAIL PROTECTED]
