e se outra pessoa tiver um programa com objectos gráficos, o seu tipo de prefixo "l" < onde é a eliminação por prefixo " l" (os nomes "label" e "line" foram usados quando os objectos foram criados >
Irá matar todos os objectos que comecem por"l" num programa de terceiros. Esta não é uma boa solução.
Vitaly, porque não entra na linha dos principiantes? Estas noções básicas mais ou menos que o programador conhece há muito tempo. E só as "estrelas" não sabem todas...
Vitaly, porque não entra na linha dos principiantes? Estes princípios básicos são conhecidos há mais ou menos tempo pelos programadores. E só as "estrelas" não sabem todas...
e se outra pessoa tiver um programa com objectos gráficos, o seu tipo de prefixo "l" < onde é a eliminação por prefixo " l" (os nomes "label" e "line" foram usados quando os objectos foram criados >
Irá matar todos os objectos que comecem por"l" num programa de terceiros. Esta não é uma boa solução.
Era o que eu também estava a pensar. Há uma hipótese de outro programador colar nomes de objectos idênticos ou nomes com o mesmo prefixo, pelo que remover objectos por prefixo (especialmente o curto) é mais perigoso do que esbarrar e remover um objecto com um nome completamente coincidente. Devemos também ter em mente que um segundo programa não será capaz de criar um segundo objecto com um nome existente, o primeiro objecto deve permanecer (na minha opinião). Em qualquer caso, um programa vizinho que decida apagar um tal objecto, assumindo que é o seu objecto, apagará o objecto de outra pessoa com o mesmo nome.
Até agora, vejo a única solução: nomear objectos dentro do mesmo programa o mais exclusivamente possível, para reduzir a hipótese de tropeçar num objecto alienígena com o mesmo nome e fazer manipulações indesejáveis sobre ele. Mas deixem-me lembrar-vos que o alongamento do prefixo nem sempre é tecnicamente possível, porque o comprimento do nome do objecto é limitado.
Era o que eu também estava a pensar. Há uma hipótese de outro programador fazer nomes de objectos idênticos ou nomes com o mesmo prefixo, pelo que apagar objectos por prefixo (especialmente um curto) é mais perigoso do que esbarrar e apagar um objecto totalmente compatível pelo nome. Devemos também ter em mente que um segundo programa não será capaz de criar um segundo objecto com um nome existente, o primeiro objecto deve permanecer (na minha opinião). Em qualquer caso, um segundo programa que decida apagar um tal objecto, assumindo que é o seu objecto, apagará o objecto de outra pessoa com o mesmo nome.
Até agora, vejo a única solução: nomear objectos dentro do mesmo programa o mais exclusivamente possível, para reduzir a probabilidade de tropeçar num objecto alienígena com o mesmo nome e fazer manipulações indesejáveis sobre ele. Mas deixem-me lembrar-vos que o alongamento do prefixo nem sempre é tecnicamente possível, porque o comprimento do nome do objecto é limitado.
Não preciso de vos lembrar, trabalho todos os dias com objectos gráficos.
Lógica incorrecta é a chave para ... o quê? Certo, a chave para o fracasso. Esse é o seu caso.
Não preciso de me lembrar, trabalho todos os dias com objectos gráficos.
Lógica incorrecta é a chave para... o quê? Certo, a chave para o fracasso. Esse é o seu caso.
E o que é o fracasso?
E lembro-vos, em geral, não de vós (não estamos em correspondência privada), mas sim do público que nos lê, entre os quais estou certo de que há amadores.
Compreendo que se tenha esforçado muito para escrever, por isso para si este programa é valioso e correcto. Mas há falhas, mesmo críticas, que é difícil de aceitar.
É tudo, resolvam por vossa conta, eu descrevi a minha avaliação.
Desaconselhei-o de forma abrangente, admitindo que tem razão apenas em alguns pontos não críticos de menor importância. Mas se não ficar impressionado e dissuadido, eu compreendo - é difícil aceitar os contra-argumentos directamente do autor do código.
Tente adivinhar que percentagem de programadores procura programas para ajudar a sua comercialização lucrativa ou para aprender o código. Pessoalmente, penso que a preponderância estará na direcção dos primeiros, porque muito menos buscadores se vêem a si próprios como programadores neste campo.
Tente adivinhar que percentagem de programadores procura programas para ajudar a sua comercialização lucrativa ou para aprender o código. Pessoalmente, acredito que a preponderância é mais a favor da primeira, uma vez que muito menos daqueles que a procuram se vêem a si próprios como programadores neste campo.
A questão é que tal código não pode ser usado numa máquina pessoal, mas nunca se reconheceu isto. Um programador certamente não o vai colocar, tendo visto o que está dentro do código.
Eles também começaram a discutir sobre o prefixo, mas eu não vim aqui para discutir.
O problema é esse: não se pode usar esse código numa máquina pessoal, mas nunca se reconhece.
Claro que não o fiz. Porque para que esses defeitos comecem a abrandar a máquina, é necessário utilizá-los em cálculos de alta carga - por exemplo, em loops muito, muito gordos ou reinicializações muito frequentes. Não recomendo a adopção deste código para tais casos. Mas no presente caso tudo voa; a afirmação ruidosa e contraditória sobre o fracasso não é mais do que uma humilhação. Mas obrigado por isso.
E estou sempre aberto a melhorar o meu código à medida que me torno mais iluminado.
e se outra pessoa tiver um programa com objectos gráficos, o seu tipo de prefixo "l" < onde é a eliminação por prefixo " l" (os nomes "label" e "line" foram usados quando os objectos foram criados >
Irá matar todos os objectos que comecem por"l" num programa de terceiros. Esta não é uma boa solução.
Vitaly, porque não entra na linha dos principiantes? Estas noções básicas mais ou menos que o programador conhece há muito tempo. E só as "estrelas" não sabem todas...
Vitaly, porque não entra na linha dos principiantes? Estes princípios básicos são conhecidos há mais ou menos tempo pelos programadores. E só as "estrelas" não sabem todas...
Óptimo!
Sim, eu provavelmente irei :)
e se outra pessoa tiver um programa com objectos gráficos, o seu tipo de prefixo "l" < onde é a eliminação por prefixo " l" (os nomes "label" e "line" foram usados quando os objectos foram criados >
Irá matar todos os objectos que comecem por"l" num programa de terceiros. Esta não é uma boa solução.
Era o que eu também estava a pensar. Há uma hipótese de outro programador colar nomes de objectos idênticos ou nomes com o mesmo prefixo, pelo que remover objectos por prefixo (especialmente o curto) é mais perigoso do que esbarrar e remover um objecto com um nome completamente coincidente. Devemos também ter em mente que um segundo programa não será capaz de criar um segundo objecto com um nome existente, o primeiro objecto deve permanecer (na minha opinião). Em qualquer caso, um programa vizinho que decida apagar um tal objecto, assumindo que é o seu objecto, apagará o objecto de outra pessoa com o mesmo nome.
Até agora, vejo a única solução: nomear objectos dentro do mesmo programa o mais exclusivamente possível, para reduzir a hipótese de tropeçar num objecto alienígena com o mesmo nome e fazer manipulações indesejáveis sobre ele. Mas deixem-me lembrar-vos que o alongamento do prefixo nem sempre é tecnicamente possível, porque o comprimento do nome do objecto é limitado.
Era o que eu também estava a pensar. Há uma hipótese de outro programador fazer nomes de objectos idênticos ou nomes com o mesmo prefixo, pelo que apagar objectos por prefixo (especialmente um curto) é mais perigoso do que esbarrar e apagar um objecto totalmente compatível pelo nome. Devemos também ter em mente que um segundo programa não será capaz de criar um segundo objecto com um nome existente, o primeiro objecto deve permanecer (na minha opinião). Em qualquer caso, um segundo programa que decida apagar um tal objecto, assumindo que é o seu objecto, apagará o objecto de outra pessoa com o mesmo nome.
Até agora, vejo a única solução: nomear objectos dentro do mesmo programa o mais exclusivamente possível, para reduzir a probabilidade de tropeçar num objecto alienígena com o mesmo nome e fazer manipulações indesejáveis sobre ele. Mas deixem-me lembrar-vos que o alongamento do prefixo nem sempre é tecnicamente possível, porque o comprimento do nome do objecto é limitado.
Não preciso de vos lembrar, trabalho todos os dias com objectos gráficos.
Lógica incorrecta é a chave para ... o quê? Certo, a chave para o fracasso. Esse é o seu caso.
Não preciso de me lembrar, trabalho todos os dias com objectos gráficos.
Lógica incorrecta é a chave para... o quê? Certo, a chave para o fracasso. Esse é o seu caso.
E o que é o fracasso?
E lembro-vos, em geral, não de vós (não estamos em correspondência privada), mas sim do público que nos lê, entre os quais estou certo de que há amadores.E o que é o fracasso?
Já o descrevi, mas a escolha é sua.
Compreendo que se tenha esforçado muito para escrever, por isso para si este programa é valioso e correcto. Mas há falhas, mesmo críticas, que é difícil de aceitar.
É tudo, resolvam por vossa conta, eu descrevi a minha avaliação.
Já o descrevi, mas a escolha é sua.
Desaconselhei-o de forma abrangente, admitindo que tem razão apenas em alguns pontos não críticos de menor importância. Mas se não ficar impressionado e dissuadido, eu compreendo - é difícil aceitar os contra-argumentos directamente do autor do código.
Por falar em procura de código livre.
Tente adivinhar que percentagem de programadores procura programas para ajudar a sua comercialização lucrativa ou para aprender o código. Pessoalmente, penso que a preponderância estará na direcção dos primeiros, porque muito menos buscadores se vêem a si próprios como programadores neste campo.
Por falar em procura de código livre.
Tente adivinhar que percentagem de programadores procura programas para ajudar a sua comercialização lucrativa ou para aprender o código. Pessoalmente, acredito que a preponderância é mais a favor da primeira, uma vez que muito menos daqueles que a procuram se vêem a si próprios como programadores neste campo.
A questão é que tal código não pode ser usado numa máquina pessoal, mas nunca se reconheceu isto. Um programador certamente não o vai colocar, tendo visto o que está dentro do código.
Eles também começaram a discutir sobre o prefixo, mas eu não vim aqui para discutir.
Boa sorte!
O problema é esse: não se pode usar esse código numa máquina pessoal, mas nunca se reconhece.
Claro que não o fiz. Porque para que esses defeitos comecem a abrandar a máquina, é necessário utilizá-los em cálculos de alta carga - por exemplo, em loops muito, muito gordos ou reinicializações muito frequentes. Não recomendo a adopção deste código para tais casos. Mas no presente caso tudo voa; a afirmação ruidosa e contraditória sobre o fracasso não é mais do que uma humilhação. Mas obrigado por isso.
E estou sempre aberto a melhorar o meu código à medida que me torno mais iluminado.