Sim sao pastinhas pra organizar suas classe ex: simples crie uma pasta
chamada verduras por exemplo, dentro dela vc cria a classe abobrinha
package verduras {
public class Abobrinha
{
}
}
crie tb a classe tomate
package verduras {
public class Tomate
{
}
}
na hora de usar vc importa
import verduras
aii vc pode criar instancias dessas classes que estao na verduras:
var verduradodia:Tomate = new Tomate();
;-)
Ricardo
On 19 jun, 12:53, Emanuel Mandelli <[EMAIL PROTECTED]> wrote:
> Obrigado pelas respostas. :D
>
> No livro diz que podemos criar nossos próprios namespaces, nessa parte
> que eu me embananei! :/
>
> Alguém tem algum exemplo?
>
> Tuesday, June 19, 2007, 10:28:06 AM, you wrote:
>
>
>
>
>
>
>
> > Outra coisa bacana que eu vi na documentacao () é que se vc tiver duas
> > classes com o mesmo nome em pacotes diferentes e precisar utilizar
> > instancias delas no mesmo local da pra criar apelidos:
> > package acme.core
> > {
> > public class Widget { }
> > }
> > package mx.core
> > {
> > public class Widget { }
> > }
> > import AcmeWidget = acme.core.Widget
> > import MxWidget = mx.core.Widget
> >http://livedocs.adobe.com/specs/actionscript/3/wwhelp/wwhimpl/common/...
> > new AcmeWidget
> > new MxWidget
> > Beck, valeu... finalmente acho que entendi o protected, hehehehe, ve
> > se é isso:
> > se eu declarasse como private eu nao poderia usar o override quando
> > fizesse uma heranca dessa classe, é isso ?
> > Ricardo
> > On 19 jun, 08:24, Beck Novaes <[EMAIL PROTECTED]> wrote:
> >> Uma boa maneira de compreender os namespaces é através dos
> >> modificadores de acesso. Estes elementos controlam a visibilidade das
> >> propriedades e métodos de uma classe. Muitas linguagens possuem três
> >> modificadores de acesso: private, protected e public. Os modificadores
> >> de acesso permitem ao programador limitar o acesso a determinados
> >> elementos e assim garantir um bom encapsulamento. Quando você diz que
> >> alguma coisa é "public", por exemplo, você está dizendo: "pessoas,
> >> usem isto aqui a vontade porque isto não irá mudar". Por outro lado,
> >> quando você torna algo "private" ninguém poderá usar e você é livre
> >> para alterar como quiser. O "protected" está no meio do caminho ao
> >> permitir que os elementos sejam alterados dentro de um escopo
> >> (herança) mais limitado que o "public", porém menos rígido que o
> >> "private". Por fim, cabe dizer que os modificadores de acesso ajudam a
> >> fazer o que é mais importante em programação: lidar com a
> >> complexidade. Quando todo mundo pode mexer em tudo, tais como
> >> variáveis Globais, tica difícil para o programador ter que lembrar
> >> quais os locais que determinado elemento foi utilizado. Mas quando
> >> você limita o escopo/acesso dos elementos fica mais fácil de gerenciar
> >> este tipo de coisa.
>
> >> Agora o que os namespaces têm a ver com tudo isto? Bem, você pode
> >> pensar nos modificadores de acesso padrão do ActionScript (internal,
> >> private, protected e public) como namespaces pré-definidos. Isto
> >> significa que você pode implementar seu próprio modificador de acesso
> >> e assim estabelecer um nível de controle a mais, que lhe ajudará a
> >> lidar melhor com a complexidade. Imagine que você possui um conjunto
> >> de classes que fazem parte de um framework que você está
> >> desenvolvendo. De repente você percebe que a classe "A" precisa chamar
> >> o método "test" num objeto da classe "B" que está num pacote
> >> diferente. Mas você não quer tornar o método "test" public porque ele
> >> é de uso interno do seu framework. O que você faz? Bem, você pode
> >> criar um namespace chamado "framework" e defini-lo como o modificador
> >> de acesso do método "test". Na realidade é isto que a Adobe fez com
> >> muitos elementos do SDK do Flex. Se você abrir a classe UIComponent
> >> verá que existe um modificador de acesso "mx_internal". Isto permite
> >> que os componentes do SDK tenham acesso a estes elementos mesmo
> >> estando em pacotes diferentes ao mesmo tempo em que estes elementos
> >> não são públicos "naturalmente". Eu digo "naturalmente" porque sei que
> >> existe uma maneira de usar estes elementos mesmo eles não sendo
> >> públicos. Porém não devemos usá-los, pois se não são explicitamente
> >> públicos a Adobe poderá modificá-los amanha e o nosso programa que fez
> >> o uso indiscriminado destes elementos "mx_internal" irá parar de
> >> funcionar.
>
> >> Existem outros cenários onde o uso de namespaces pode ser conveniente,
> >> mas acho que já escrevi demais. :-D
>
> >> On 18 jun, 17:49, Emanuel Mandelli <[EMAIL PROTECTED]> wrote:
>
> >> > Olá pessoal, tudo bem?
>
> >> > Alguém poderia me explicar namespaces? Estou lendo um livro em inglês
> >> > mas não estou entendendo.
>
> >> > --
> >> > Abraços,
> >> > Emanuel
> >> > [EMAIL PROTECTED]
>
> --
> Abraços,
> Emanuel
> [EMAIL PROTECTED]
--~--~---------~--~----~------------~-------~--~----~
Você recebeu esta mensagem porque está inscrito na lista "flexdev"
Para enviar uma mensagem, envie um e-mail para flexdev@googlegroups.com
Para sair da lista, envie um email em branco para [EMAIL PROTECTED]
Mais opções estão disponíveis em http://groups.google.com/group/flexdev
-~----------~----~----~----~------~----~------~--~---
