Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Whoohoo, a lot of explicit coders here :D
Steven Sacks wrote:
Taka,
When you're done building your Straw Man, you let me know and I'll
happily continue the discussion with you.
Cheers,
Steven
Taka Kojima wrote:
Writing readable code > writing less code.
That is what it comes down to. Most coders can understand both of the
following:
if(myObj){;}
and
if(myObj != null){;}
I would opt for the latter method always, as otherwise you are
relying on
renderer specific logic to handle the conversion, as opposed to explicit
conversion.
I have actually spent an hr trying to debug an IE specific JS error,
only to
find that even though implicit type conversion was working in other
browsers, it was throwing an error in a specific version of IE.
By your argument of less code > more code, this:
public function outputList():*{;}
would be better than
public function outputList():Array{;}
and AS2 would be better than AS3 on the whole basis that you didn't
have to
typecast anything.
Just because a certain environment can convert types for you, doesn't
mean
that you shouldn't typecast or not hint as to their object type in your
code.
Personally, I can type faster than I can think in code. I type really
fast,
and I think code really fast, and typing out the extra 10 characters
doesn't
hinder my productivity, it probably enhances it.
If you want to take the implicit convesion route, by all means I am not
going to stop you or object. However, I do and will always believe
that it
is better for other people reading/working on your code that you do
spell it
all out, use line breaks when it makes sense, and typecast all your
variables.
I think Dave's point was that you seemed rather authoritative, and
this is
really a subjective matter.
- Taka
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Taka,
When you're done building your Straw Man, you let me know and I'll happily
continue the discussion with you.
Cheers,
Steven
Taka Kojima wrote:
Writing readable code > writing less code.
That is what it comes down to. Most coders can understand both of the
following:
if(myObj){;}
and
if(myObj != null){;}
I would opt for the latter method always, as otherwise you are relying on
renderer specific logic to handle the conversion, as opposed to explicit
conversion.
I have actually spent an hr trying to debug an IE specific JS error, only to
find that even though implicit type conversion was working in other
browsers, it was throwing an error in a specific version of IE.
By your argument of less code > more code, this:
public function outputList():*{;}
would be better than
public function outputList():Array{;}
and AS2 would be better than AS3 on the whole basis that you didn't have to
typecast anything.
Just because a certain environment can convert types for you, doesn't mean
that you shouldn't typecast or not hint as to their object type in your
code.
Personally, I can type faster than I can think in code. I type really fast,
and I think code really fast, and typing out the extra 10 characters doesn't
hinder my productivity, it probably enhances it.
If you want to take the implicit convesion route, by all means I am not
going to stop you or object. However, I do and will always believe that it
is better for other people reading/working on your code that you do spell it
all out, use line breaks when it makes sense, and typecast all your
variables.
I think Dave's point was that you seemed rather authoritative, and this is
really a subjective matter.
- Taka
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
That's plain bad english, I assure you :)"A good CODER must go beyond a good CODE and be fast when needed." Leandro Ferreira On Tue, Aug 18, 2009 at 22:02, Peter B wrote: > 2009/8/19 Leandro Ferreira : > > A good CODER must go beyond a good CODE be fast when needed. That's MHO, > and > > It gets clear when we compare the number of lines we use to express > > ourselves. > > > > Indeed. And you unintentionally help to illustrate the point. Paul's > post, though long, is clear in what it communicates. Your post is > brief, but I am finding it difficult to extract any meaning from it. > ___ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Writing readable code > writing less code.
That is what it comes down to. Most coders can understand both of the
following:
if(myObj){;}
and
if(myObj != null){;}
I would opt for the latter method always, as otherwise you are relying on
renderer specific logic to handle the conversion, as opposed to explicit
conversion.
I have actually spent an hr trying to debug an IE specific JS error, only to
find that even though implicit type conversion was working in other
browsers, it was throwing an error in a specific version of IE.
By your argument of less code > more code, this:
public function outputList():*{;}
would be better than
public function outputList():Array{;}
and AS2 would be better than AS3 on the whole basis that you didn't have to
typecast anything.
Just because a certain environment can convert types for you, doesn't mean
that you shouldn't typecast or not hint as to their object type in your
code.
Personally, I can type faster than I can think in code. I type really fast,
and I think code really fast, and typing out the extra 10 characters doesn't
hinder my productivity, it probably enhances it.
If you want to take the implicit convesion route, by all means I am not
going to stop you or object. However, I do and will always believe that it
is better for other people reading/working on your code that you do spell it
all out, use line breaks when it makes sense, and typecast all your
variables.
I think Dave's point was that you seemed rather authoritative, and this is
really a subjective matter.
- Taka
On Tue, Aug 18, 2009 at 6:02 PM, Peter B wrote:
> 2009/8/19 Leandro Ferreira :
> > A good CODER must go beyond a good CODE be fast when needed. That's MHO,
> and
> > It gets clear when we compare the number of lines we use to express
> > ourselves.
> >
>
> Indeed. And you unintentionally help to illustrate the point. Paul's
> post, though long, is clear in what it communicates. Your post is
> brief, but I am finding it difficult to extract any meaning from it.
> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
2009/8/19 Leandro Ferreira : > A good CODER must go beyond a good CODE be fast when needed. That's MHO, and > It gets clear when we compare the number of lines we use to express > ourselves. > Indeed. And you unintentionally help to illustrate the point. Paul's post, though long, is clear in what it communicates. Your post is brief, but I am finding it difficult to extract any meaning from it. ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Can I get a copy of this thread in paperback? You can not find this
stuff anywhere else in the world. I was actually going to ask where I
could get some info on coding best practices and go buy a book, but I
am glad I saved my money.
;)
Karl
Sent from losPhone
On Aug 18, 2009, at 4:58 PM, Patrick Matte
wrote:
I think you're right, but I saw one guy here at work writing
something like
this for readability he said!
if (value != null) {
;
} else if (value == null) {
;
}
From: Paul Andrews
Reply-To: Flash Coders List
Date: Tue, 18 Aug 2009 22:17:05 +0100
To: Flash Coders List
Subject: Re: [Flashcoders] How to add a DisplayObject into a
container without
using addChild() method.
Dave Watts wrote:
snip
It really depends on the language. Since I'm moving (more or less)
from Java to AS3, more or less, I'm usually using explicit
expressions
because that's what people do in Java. On the other hand, in the
ColdFusion code I've written, I usually use implicit Boolean
evaluation.
I don't think writing "good" code is related to languages, despite
the
different constructs available between them. I think good coding
style
is based on simple principles, and brevity or speed of coding is not
included.
Short coding constructs may be perceived as elegant and aid coding
speed, but that wholly misses the point - coding isn't a race nor is
optimising the number of bytes in the source code. Showing a deep
knowledge of a software language through use of the language in ways
that are not so clear to mere mortals less familiar with the
language,
isn't good. It is rarely a good idea to optimise code by using a
faster
programming construct that makes the intention of the code less
clear.
Good coding should be clear - even for those less familiar with the
language. Truncated coding constructs may be efficient and even
elegant,
but will they be easily understandable by someone else (or even the
same
person much later)? Code minimalism can hide the true intention of
the
code and introduce unintended behaviour when mistakes are made. When
code is expansive (verbose even) the intention of the code is clear.
When someone relies on some language behaviour for handling null
values,
the reader may be left wondering whether the original developer
really
intended that the code should handle nulls in this way, or is it some
accidental happenstance of using that construct? Are nulls really
relevant here in this code snippet or not. Testing specifically for
nulls is explicit and unambiguous.
Maintainability - truncated constructs can sometimes mean that
changes
for updates mean undoing the "efficient" constructs that performed
well
for specific case they were coded for, but will have to be ditched
completely for the more complicated case, leaving the updater to
unwind
the intention of the shorter construct and translate that to the
wider case.
As far as "fast" coding goes, everybody likes a helpful ide or
editor,
but really fast coders really aren't team coders and the "need for
speed" is less important than the need for clarity. I'm not a fast
coder. Sometimes I wish I was an even slower coder, because then I'd
realise I could code things rather better than going rushing in to
get
things done.
I once worked with a guy who had a clear desk and often sat reading
the
newspaper. It did attract some critical comment, but that guy had the
right idea. Before he started coding he spent a lot of time on the
design, getting that right. A faster code editor or fancy programming
wouldn't have made him a better developer. He spent most of his time
getting it right before his hands hit the keyboard. He was the best
developer I ever met.
So, in my insignificant opinion - brevity == BAD, fast coding ==BAD.
Paul
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Software provides the highest caliber vendor-authorized
instruction at our training centers in Washington DC, Atlanta,
Chicago, Baltimore, Northern Virginia, or on-site at your location.
Visit http://training.figleaf.com/ for more information!
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
This e-mail is intended only for the named person or entity to which
it is addressed and contains valuable
business information that is proprietary, privileged, confidential
and/or otherwise protected from disclosure.
If you received this e-mail in error, any review, use,
dissemination, distribution or copying of this e-mail
is strictly prohibited. Please notify us immediately of the error
via e-mail to disclai...
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> I think you're right, but I saw one guy here at work writing something like
> this for readability he said!
>
> if (value != null) {
> ;
> } else if (value == null) {
> ;
> }
There's a difference between verbose and just plain dumb.
Dave Watts, CTO, Fig Leaf Software
http://www.figleaf.com/
Fig Leaf Software provides the highest caliber vendor-authorized
instruction at our training centers in Washington DC, Atlanta,
Chicago, Baltimore, Northern Virginia, or on-site at your location.
Visit http://training.figleaf.com/ for more information!
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: Autoreply: Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
time to suspend [email protected] I'd say [email protected] wrote: Wir haben vom 10.08.2009 - 21.08.2009 Betriebsferien. Alle Anfragen werden wir danach umgehend beantworten. Vielen Dank für Ihr Verständnis. ### We are closed for vacation from Aug 10, 2009 until Aug 21, 2009. All requests will be answered after Aug 21, 2009. Thanks for your patience. ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
We might want to change the subjet line. Our ACElash-friend must have gotten scared from the responses on his question how he should do a parent.addchild(self) :) Anyways in my perception a long list of if elses is not always my ideal of readable code. ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
I think you're right, but I saw one guy here at work writing something like
this for readability he said!
if (value != null) {
;
} else if (value == null) {
;
}
> From: Paul Andrews
> Reply-To: Flash Coders List
> Date: Tue, 18 Aug 2009 22:17:05 +0100
> To: Flash Coders List
> Subject: Re: [Flashcoders] How to add a DisplayObject into a container without
> using addChild() method.
>
> Dave Watts wrote:
>> snip
>> It really depends on the language. Since I'm moving (more or less)
>> from Java to AS3, more or less, I'm usually using explicit expressions
>> because that's what people do in Java. On the other hand, in the
>> ColdFusion code I've written, I usually use implicit Boolean
>> evaluation.
>>
> I don't think writing "good" code is related to languages, despite the
> different constructs available between them. I think good coding style
> is based on simple principles, and brevity or speed of coding is not
> included.
>
> Short coding constructs may be perceived as elegant and aid coding
> speed, but that wholly misses the point - coding isn't a race nor is
> optimising the number of bytes in the source code. Showing a deep
> knowledge of a software language through use of the language in ways
> that are not so clear to mere mortals less familiar with the language,
> isn't good. It is rarely a good idea to optimise code by using a faster
> programming construct that makes the intention of the code less clear.
>
> Good coding should be clear - even for those less familiar with the
> language. Truncated coding constructs may be efficient and even elegant,
> but will they be easily understandable by someone else (or even the same
> person much later)? Code minimalism can hide the true intention of the
> code and introduce unintended behaviour when mistakes are made. When
> code is expansive (verbose even) the intention of the code is clear.
> When someone relies on some language behaviour for handling null values,
> the reader may be left wondering whether the original developer really
> intended that the code should handle nulls in this way, or is it some
> accidental happenstance of using that construct? Are nulls really
> relevant here in this code snippet or not. Testing specifically for
> nulls is explicit and unambiguous.
>
> Maintainability - truncated constructs can sometimes mean that changes
> for updates mean undoing the "efficient" constructs that performed well
> for specific case they were coded for, but will have to be ditched
> completely for the more complicated case, leaving the updater to unwind
> the intention of the shorter construct and translate that to the wider case.
>
> As far as "fast" coding goes, everybody likes a helpful ide or editor,
> but really fast coders really aren't team coders and the "need for
> speed" is less important than the need for clarity. I'm not a fast
> coder. Sometimes I wish I was an even slower coder, because then I'd
> realise I could code things rather better than going rushing in to get
> things done.
>
> I once worked with a guy who had a clear desk and often sat reading the
> newspaper. It did attract some critical comment, but that guy had the
> right idea. Before he started coding he spent a lot of time on the
> design, getting that right. A faster code editor or fancy programming
> wouldn't have made him a better developer. He spent most of his time
> getting it right before his hands hit the keyboard. He was the best
> developer I ever met.
>
> So, in my insignificant opinion - brevity == BAD, fast coding ==BAD.
>
> Paul
>
>> Dave Watts, CTO, Fig Leaf Software
>> http://www.figleaf.com/
>>
>> Fig Leaf Software provides the highest caliber vendor-authorized
>> instruction at our training centers in Washington DC, Atlanta,
>> Chicago, Baltimore, Northern Virginia, or on-site at your location.
>> Visit http://training.figleaf.com/ for more information!
>>
>> ___
>> Flashcoders mailing list
>> [email protected]
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
This e-mail is intended only for the named person or entity to which it is
addressed and contains valuable
business information that is proprietary, privileged, confidential and/or
otherwise protected from disclosure.
If you received this e-mail in error, any review, use, dissemination,
distribution or copying of this e-mail
is strictly prohibited. Please notify us immediately of the error via e-mail to
[email protected] and
please delete the e-mail from your system, retaining no copies in any media. We
appreciate your cooperation.
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
A good CODER must go beyond a good CODE be fast when needed. That's MHO, and It gets clear when we compare the number of lines we use to express ourselves. Leandro Ferreira Sent from Brasília, Brazilian Federal District, Brazil On Tue, Aug 18, 2009 at 18:17, Paul Andrews wrote: > Dave Watts wrote: > >> snip >> It really depends on the language. Since I'm moving (more or less) >> from Java to AS3, more or less, I'm usually using explicit expressions >> because that's what people do in Java. On the other hand, in the >> ColdFusion code I've written, I usually use implicit Boolean >> evaluation. >> >> > I don't think writing "good" code is related to languages, despite the > different constructs available between them. I think good coding style is > based on simple principles, and brevity or speed of coding is not included. > > Short coding constructs may be perceived as elegant and aid coding speed, > but that wholly misses the point - coding isn't a race nor is optimising the > number of bytes in the source code. Showing a deep knowledge of a software > language through use of the language in ways that are not so clear to mere > mortals less familiar with the language, isn't good. It is rarely a good > idea to optimise code by using a faster programming construct that makes the > intention of the code less clear. > > Good coding should be clear - even for those less familiar with the > language. Truncated coding constructs may be efficient and even elegant, but > will they be easily understandable by someone else (or even the same person > much later)? Code minimalism can hide the true intention of the code and > introduce unintended behaviour when mistakes are made. When code is > expansive (verbose even) the intention of the code is clear. When someone > relies on some language behaviour for handling null values, the reader may > be left wondering whether the original developer really intended that the > code should handle nulls in this way, or is it some accidental happenstance > of using that construct? Are nulls really relevant here in this code snippet > or not. Testing specifically for nulls is explicit and unambiguous. > > Maintainability - truncated constructs can sometimes mean that changes for > updates mean undoing the "efficient" constructs that performed well for > specific case they were coded for, but will have to be ditched completely > for the more complicated case, leaving the updater to unwind the intention > of the shorter construct and translate that to the wider case. > > As far as "fast" coding goes, everybody likes a helpful ide or editor, but > really fast coders really aren't team coders and the "need for speed" is > less important than the need for clarity. I'm not a fast coder. Sometimes I > wish I was an even slower coder, because then I'd realise I could code > things rather better than going rushing in to get things done. > > I once worked with a guy who had a clear desk and often sat reading the > newspaper. It did attract some critical comment, but that guy had the right > idea. Before he started coding he spent a lot of time on the design, getting > that right. A faster code editor or fancy programming wouldn't have made him > a better developer. He spent most of his time getting it right before his > hands hit the keyboard. He was the best developer I ever met. > > So, in my insignificant opinion - brevity == BAD, fast coding ==BAD. > > Paul > > > Dave Watts, CTO, Fig Leaf Software >> http://www.figleaf.com/ >> >> Fig Leaf Software provides the highest caliber vendor-authorized >> instruction at our training centers in Washington DC, Atlanta, >> Chicago, Baltimore, Northern Virginia, or on-site at your location. >> Visit http://training.figleaf.com/ for more information! >> >> ___ >> Flashcoders mailing list >> [email protected] >> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders >> >> > ___ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Dave Watts wrote: snip It really depends on the language. Since I'm moving (more or less) from Java to AS3, more or less, I'm usually using explicit expressions because that's what people do in Java. On the other hand, in the ColdFusion code I've written, I usually use implicit Boolean evaluation. I don't think writing "good" code is related to languages, despite the different constructs available between them. I think good coding style is based on simple principles, and brevity or speed of coding is not included. Short coding constructs may be perceived as elegant and aid coding speed, but that wholly misses the point - coding isn't a race nor is optimising the number of bytes in the source code. Showing a deep knowledge of a software language through use of the language in ways that are not so clear to mere mortals less familiar with the language, isn't good. It is rarely a good idea to optimise code by using a faster programming construct that makes the intention of the code less clear. Good coding should be clear - even for those less familiar with the language. Truncated coding constructs may be efficient and even elegant, but will they be easily understandable by someone else (or even the same person much later)? Code minimalism can hide the true intention of the code and introduce unintended behaviour when mistakes are made. When code is expansive (verbose even) the intention of the code is clear. When someone relies on some language behaviour for handling null values, the reader may be left wondering whether the original developer really intended that the code should handle nulls in this way, or is it some accidental happenstance of using that construct? Are nulls really relevant here in this code snippet or not. Testing specifically for nulls is explicit and unambiguous. Maintainability - truncated constructs can sometimes mean that changes for updates mean undoing the "efficient" constructs that performed well for specific case they were coded for, but will have to be ditched completely for the more complicated case, leaving the updater to unwind the intention of the shorter construct and translate that to the wider case. As far as "fast" coding goes, everybody likes a helpful ide or editor, but really fast coders really aren't team coders and the "need for speed" is less important than the need for clarity. I'm not a fast coder. Sometimes I wish I was an even slower coder, because then I'd realise I could code things rather better than going rushing in to get things done. I once worked with a guy who had a clear desk and often sat reading the newspaper. It did attract some critical comment, but that guy had the right idea. Before he started coding he spent a lot of time on the design, getting that right. A faster code editor or fancy programming wouldn't have made him a better developer. He spent most of his time getting it right before his hands hit the keyboard. He was the best developer I ever met. So, in my insignificant opinion - brevity == BAD, fast coding ==BAD. Paul Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> The reason you're comfortable straddling the fence is because you don't > experience the pain or discomfort associated with a picket sticking into > your crotch. Why would that be? ;) Because I used to be in the military, where you routinely get screwed on a daily basis. BOHICA. > How do YOU code? Do you use implicit or explicit? It really depends on the language. Since I'm moving (more or less) from Java to AS3, more or less, I'm usually using explicit expressions because that's what people do in Java. On the other hand, in the ColdFusion code I've written, I usually use implicit Boolean evaluation. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
The reason you're comfortable straddling the fence is because you don't experience the pain or discomfort associated with a picket sticking into your crotch. Why would that be? ;) How do YOU code? Do you use implicit or explicit? Dave Watts wrote: I think you're missing the point. You're asking a pacifist which army he should join. I really don't have a strong opinion either way. ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> Dave, come on. Take a stand on the issue. Stop straddling the fence. > > Pick a side. Im or Ex? I think you're missing the point. You're asking a pacifist which army he should join. I really don't have a strong opinion either way. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Back when I was using AS2 and Javascript "||" operator was useful to me. I was so glad when AS3 brought default parameters. var value:String = foo || bar; -- Keith H -- www.keith-hair.net Steven Sacks wrote: Dave, come on. Take a stand on the issue. Stop straddling the fence. Pick a side. Im or Ex? I'm not about writing cryptic PERL-like statements, but writing != null is a waste of time. It's obviously a null comparison (by nature of it being an instance). Calling it out as such is redundant. It also lends itself to very readable code with inline ORs. var value:String = foo || bar; If foo is null, value = bar. Great for default values such as with XML. var value:String = x...@foo || ""; Very readable and so much better than var value:String = ""; if (x...@foo != undefined) value = x...@foo; ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Dave, come on. Take a stand on the issue. Stop straddling the fence. Pick a side. Im or Ex? I'm not about writing cryptic PERL-like statements, but writing != null is a waste of time. It's obviously a null comparison (by nature of it being an instance). Calling it out as such is redundant. It also lends itself to very readable code with inline ORs. var value:String = foo || bar; If foo is null, value = bar. Great for default values such as with XML. var value:String = x...@foo || ""; Very readable and so much better than var value:String = ""; if (x...@foo != undefined) value = x...@foo; ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
That was supposed to be a winky, not a frowny. Steven Sacks wrote: I didn't see a reponse from Ash. Yet another email lost to the ether. :( Dave Watts wrote: And as much as I like Ash, I'm not sure I want to take coding advice from the guy who couldn't remember "klaatu barada nikto" - maybe he was too enamored of shortcuts? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
I didn't see a reponse from Ash. Yet another email lost to the ether. :( Dave Watts wrote: And as much as I like Ash, I'm not sure I want to take coding advice from the guy who couldn't remember "klaatu barada nikto" - maybe he was too enamored of shortcuts? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
On Tue, Aug 18, 2009 at 4:20 PM, Dave Watts wrote: > Again, I'm not saying there's anything wrong with implicit Boolean > evaluation, I just think it's a mistake to believe it's inherently > superior to an explicit, slightly longer Boolean expression, to the > point of telling people they should replace one with another. Amen. Ian ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> Ugh, then you go and use an if statement without brackets, and on the same > line to boot! I for one, would not want to maintain your code. Hey, you're just lucky he's not using the ternary operator! After all, that would be the simplest approach. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Ugh, then you go and use an if statement without brackets, and on the same
line to boot! I for one, would not want to maintain your code.
This is in jest of course. I am not going to say doing things "shorthand" is
wrong, but there are some very valid merits to not doing the "shorthand"
methods.
On Mon, Aug 17, 2009 at 6:58 PM, Steven Sacks wrote:
> Here's the best way to write that. No try catch required.
>
> if (myDO && myDO.parent) myDO.parent.removeChild(myDO);
>
>
> Keith H wrote:
>
>>
>> Steven,
>>
>> Maybe its just me but...
>> Just doing a Boolean check on DisplayObjects always put my scripts in high
>> risk of runtime errors.
>> Especially in the case of "cleanup" operations.
>> Sometimes I might have a function that attempts removing a DisplayObject
>> that has not been "added" to the stage or has already been removed.
>>
>> So I check if the "stage" property is null for almost all cases now.
>>
>> var myDO:Sprite=new Sprite();
>> try {
>> //if (myDO) { //Creates runtime error
>> if (myDO && myDO.stage != null) {
>> myDO.parent.removeChild(myDO);
>> } } catch (e:Error) {
>> trace(e.message);
>> }
>>
>> -- Keith H --
>> www.keith-hair.net
>>
> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> I highly suggest reading "Practices of an Agile Developer" > http://www.pragprog.com/titles/pad/practices-of-an-agile-developer > > Use KISS. Stay DRY. Code less. Code smart (code S-Mart). > > Use smart shortcuts when they're available to you. Implicit boolean > coercion is one such shortcut, among many others. > > We need to get things done. We don't have the luxury that academia has to > argue about theory for months and years. You've spent as much time arguing about this as people typically spend typing out Boolean expressions in the first place. Honestly, if you're finding an extra ten or so characters a burden, you may have other problems that are unrelated to the value of using implicit Boolean evaluation. This has nothing to do with "getting things done" or "arguing about theory". But anyway, arguably, keeping it simple doesn't mean keeping it brief. An explicit Boolean expression is simpler to read and understand than an implicit Boolean evaluation. Not all languages support implicit Boolean evaluation, so I have to remember one set of rules for some environments and a different set for others - not simple. Again, I'm not saying there's anything wrong with implicit Boolean evaluation, I just think it's a mistake to believe it's inherently superior to an explicit, slightly longer Boolean expression, to the point of telling people they should replace one with another. And as much as I like Ash, I'm not sure I want to take coding advice from the guy who couldn't remember "klaatu barada nikto" - maybe he was too enamored of shortcuts? Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Thanks.
That is a better way to write the check. (Clever! you escaped from using
"null" once again LOL)
BTW I just put the "try/catch" there to demonstrate error.
-- Keith H --
www.keith-hair.net
Steven Sacks wrote:
Here's the best way to write that. No try catch required.
if (myDO && myDO.parent) myDO.parent.removeChild(myDO);
Keith H wrote:
Steven,
Maybe its just me but...
Just doing a Boolean check on DisplayObjects always put my scripts in
high risk of runtime errors.
Especially in the case of "cleanup" operations.
Sometimes I might have a function that attempts removing a
DisplayObject that has not been "added" to the stage or has already
been removed.
So I check if the "stage" property is null for almost all cases now.
var myDO:Sprite=new Sprite();
try {
//if (myDO) { //Creates runtime error
if (myDO && myDO.stage != null) {
myDO.parent.removeChild(myDO);
} } catch (e:Error) {
trace(e.message);
}
-- Keith H --
www.keith-hair.net
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
(myDO) && (myDO.stage) && ( myDO.parent.removeChild(myDO) )
;)
Latcho
Keith H wrote:
Steven,
Maybe its just me but...
Just doing a Boolean check on DisplayObjects always put my scripts in
high risk of runtime errors.
Especially in the case of "cleanup" operations.
Sometimes I might have a function that attempts removing a
DisplayObject that has not been "added" to the stage or has already
been removed.
So I check if the "stage" property is null for almost all cases now.
var myDO:Sprite=new Sprite();
try {
//if (myDO) { //Creates runtime error
if (myDO && myDO.stage != null) {
myDO.parent.removeChild(myDO);
} } catch (e:Error) {
trace(e.message);
}
-- Keith H --
www.keith-hair.net
Steven Sacks wrote:
I don't understand why you would not want to write a single line of
code in the class where it would provide the most clarity, and
instead write MORE code in another class obscuring the behavior that
is going on. In other words, you're writing more code to write the
same code. You're going to write addChild either way, why make it
more complicated than it needs to be?
Always follow the KISS principle.
BTW, Ekameleon, you should use
if (target)
Instead of
if (target != null)
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Here's the best way to write that. No try catch required.
if (myDO && myDO.parent) myDO.parent.removeChild(myDO);
Keith H wrote:
Steven,
Maybe its just me but...
Just doing a Boolean check on DisplayObjects always put my scripts in
high risk of runtime errors.
Especially in the case of "cleanup" operations.
Sometimes I might have a function that attempts removing a DisplayObject
that has not been "added" to the stage or has already been removed.
So I check if the "stage" property is null for almost all cases now.
var myDO:Sprite=new Sprite();
try {
//if (myDO) { //Creates runtime error
if (myDO && myDO.stage != null) {
myDO.parent.removeChild(myDO);
} } catch (e:Error) {
trace(e.message);
}
-- Keith H --
www.keith-hair.net
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Steven,
Maybe its just me but...
Just doing a Boolean check on DisplayObjects always put my scripts in
high risk of runtime errors.
Especially in the case of "cleanup" operations.
Sometimes I might have a function that attempts removing a DisplayObject
that has not been "added" to the stage or has already been removed.
So I check if the "stage" property is null for almost all cases now.
var myDO:Sprite=new Sprite();
try {
//if (myDO) { //Creates runtime error
if (myDO && myDO.stage != null) {
myDO.parent.removeChild(myDO);
}
} catch (e:Error) {
trace(e.message);
}
-- Keith H --
www.keith-hair.net
Steven Sacks wrote:
I don't understand why you would not want to write a single line of
code in the class where it would provide the most clarity, and instead
write MORE code in another class obscuring the behavior that is going
on. In other words, you're writing more code to write the same code.
You're going to write addChild either way, why make it more
complicated than it needs to be?
Always follow the KISS principle.
BTW, Ekameleon, you should use
if (target)
Instead of
if (target != null)
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
I highly suggest reading "Practices of an Agile Developer" http://www.pragprog.com/titles/pad/practices-of-an-agile-developer Use KISS. Stay DRY. Code less. Code smart (code S-Mart). Use smart shortcuts when they're available to you. Implicit boolean coercion is one such shortcut, among many others. We need to get things done. We don't have the luxury that academia has to argue about theory for months and years. :) ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> James Gosling got his Doctorate in CS in 1983. When did you get yours? Same time I got mine (never)? > Programming has changed quite a bit since then. > > new > old That must be why ActionScript moved from a prototype-based, loosely-typed language to a class-based, strongly-typed language, right? I thought strong typing was old and busted, and loose typing was the new hotness. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
James Gosling got his Doctorate in CS in 1983. Programming has changed quite a bit since then. new > old ;) Dave Watts wrote: And you are eating code, through your eyes and brain. :) ... and I must therefore excrete code from my fingertips. And the usefulness of this metaphor reaches a disgusting end. All that said, my point was simply that opinions differ on whether implicit Boolean conversion is good or bad, no matter how many AS3 style guide links you bust out. You say they're good, James Gosling says otherwise, I don't know who to believe. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> And you are eating code, through your eyes and brain. :) ... and I must therefore excrete code from my fingertips. And the usefulness of this metaphor reaches a disgusting end. All that said, my point was simply that opinions differ on whether implicit Boolean conversion is good or bad, no matter how many AS3 style guide links you bust out. You say they're good, James Gosling says otherwise, I don't know who to believe. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
It's called artistic license. ;) And you are eating code, through your eyes and brain. :) Dave Watts wrote: Code bloat is one of the seven deadly sins (gluttony). This is why we all name our variables things like x, y, etc instead of giving them recognizable names, right? And gluttony, really? I'm not going to EAT my code. Luxuria is a better fit, even though we actually call it "lust" nowadays. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
if someone handed me some code and the worst thing that they had done is wrote expressions long-handed, I would consider myself extremely lucky. lets get over ourselves... greg On Mon, Aug 17, 2009 at 5:44 PM, Dave Watts wrote: > > Code bloat is one of the seven deadly sins (gluttony). > > This is why we all name our variables things like x, y, etc instead of > giving them recognizable names, right? > > And gluttony, really? I'm not going to EAT my code. Luxuria is a > better fit, even though we actually call it "lust" nowadays. > > Dave Watts, CTO, Fig Leaf Software > http://www.figleaf.com/ > > Fig Leaf Software provides the highest caliber vendor-authorized > instruction at our training centers in Washington DC, Atlanta, > Chicago, Baltimore, Northern Virginia, or on-site at your location. > Visit http://training.figleaf.com/ for more information! > ___ > Flashcoders mailing list > [email protected] > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders > ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> Code bloat is one of the seven deadly sins (gluttony). This is why we all name our variables things like x, y, etc instead of giving them recognizable names, right? And gluttony, really? I'm not going to EAT my code. Luxuria is a better fit, even though we actually call it "lust" nowadays. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Dave Watts wrote: > Lots of people hate implicit Boolean conversion, and see it as a sin > against God and nature. I'm not one of those people, but I think it's > a mistake to say that implicit Boolean conversion is superior and > everyone should use it. Code bloat is one of the seven deadly sins (gluttony). Besides, something has to be superior. It's an if statement, after all. ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
if (Boolean) Everything inside an if statement is automatically coerced into a Boolean. Either it is or it isn't. It's not more clear to write != null because an if statement cannot possibly be anything other than true or false. In this case, null or not null. Writing it out is redundant (and more code). Recommended reading: http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions Specific to this case: http://opensource.adobe.com/wiki/display/flexsdk/Coding+Conventions#CodingConventions-Expressions ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
> BTW, Ekameleon, you should use > > if (target) > > Instead of > > if (target != null) Lots of people hate implicit Boolean conversion, and see it as a sin against God and nature. I'm not one of those people, but I think it's a mistake to say that implicit Boolean conversion is superior and everyone should use it. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ Fig Leaf Software provides the highest caliber vendor-authorized instruction at our training centers in Washington DC, Atlanta, Chicago, Baltimore, Northern Virginia, or on-site at your location. Visit http://training.figleaf.com/ for more information! ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Hello :)
i prefere use (target != null) ;) question of visibility and to keep the
default value of the argument in the constructor.
EKA+ :)
2009/8/17 Steven Sacks
> I don't understand why you would not want to write a single line of code in
> the class where it would provide the most clarity, and instead write MORE
> code in another class obscuring the behavior that is going on. In other
> words, you're writing more code to write the same code. You're going to
> write addChild either way, why make it more complicated than it needs to be?
>
> Always follow the KISS principle.
>
>
> BTW, Ekameleon, you should use
>
> if (target)
>
> Instead of
>
> if (target != null)
>
>
>
>
> ACE Flash wrote:
>
>> ekameleon, you are the man! so sweet.
>>
>> Thanks
>>
>> On Mon, Aug 17, 2009 at 1:54 PM, ekameleon wrote:
>>
>> Hello :)
>>> Use an argument in the constructor of you class to passed-in the parent
>>> reference of your display
>>>
>>> public function MyDisplay( target:DisplayObjectContainer = null )
>>> {
>>> if ( target != null )
>>> {
>>>target.addChild( this ) ;
>>> }
>>> }
>>>
>>> PS : your code isn't valid in the constructor of a DisplayObject the
>>> "stage"
>>> and "parent" properties are "null" ! Only in the main class of your
>>> application this two attributes are not null.
>>>
>>> EKA+ :)
>>>
>>> 2009/8/17 ACE Flash
>>>
>>> Hi guys,
I am curious about if am able to add the DisplayObject into a container
without using addChild() method, this class is very simple...
1. package
2. {
3. import flash.display.Sprite;
4. import flash.events.Event;
5.
6. public class MyClass extends Sprite
7. {
8.
9. public function MyClass ()
10. {
11. //addEventListener( Event.ADDED_TO_STAGE , addedHandler );
12. parent.addChild(this);
13. }
14. /*
15. private function addedHandler( e:Event ):void
16. {
17. removeEventListener( Event.ADDED_TO_STAGE , addedHandler );
18.
19. parent.addChild(this); // how could I retrieve the instance name of
this"?
20. }
21. */
22. }
23. }
I'd like to do something like
var do:MyClass = new MyClass();
//addChild(do) // added it into displayobject without using this method
here
Is that possible? any suggestions are welcome :)
Thank you
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
>>> Flashcoders mailing list
>>> [email protected]
>>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>>
>>> ___
>> Flashcoders mailing list
>> [email protected]
>> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>>
>> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
why? BTW, Ekameleon, you should use if (target) Instead of if (target != null) ___ Flashcoders mailing list [email protected] http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
I don't understand why you would not want to write a single line of code in the
class where it would provide the most clarity, and instead write MORE code in
another class obscuring the behavior that is going on. In other words, you're
writing more code to write the same code. You're going to write addChild either
way, why make it more complicated than it needs to be?
Always follow the KISS principle.
BTW, Ekameleon, you should use
if (target)
Instead of
if (target != null)
ACE Flash wrote:
ekameleon, you are the man! so sweet.
Thanks
On Mon, Aug 17, 2009 at 1:54 PM, ekameleon wrote:
Hello :)
Use an argument in the constructor of you class to passed-in the parent
reference of your display
public function MyDisplay( target:DisplayObjectContainer = null )
{
if ( target != null )
{
target.addChild( this ) ;
}
}
PS : your code isn't valid in the constructor of a DisplayObject the
"stage"
and "parent" properties are "null" ! Only in the main class of your
application this two attributes are not null.
EKA+ :)
2009/8/17 ACE Flash
Hi guys,
I am curious about if am able to add the DisplayObject into a container
without using addChild() method, this class is very simple...
1. package
2. {
3. import flash.display.Sprite;
4. import flash.events.Event;
5.
6. public class MyClass extends Sprite
7. {
8.
9. public function MyClass ()
10. {
11. //addEventListener( Event.ADDED_TO_STAGE , addedHandler );
12. parent.addChild(this);
13. }
14. /*
15. private function addedHandler( e:Event ):void
16. {
17. removeEventListener( Event.ADDED_TO_STAGE , addedHandler );
18.
19. parent.addChild(this); // how could I retrieve the instance name of
this"?
20. }
21. */
22. }
23. }
I'd like to do something like
var do:MyClass = new MyClass();
//addChild(do) // added it into displayobject without using this method
here
Is that possible? any suggestions are welcome :)
Thank you
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
ekameleon, you are the man! so sweet.
Thanks
On Mon, Aug 17, 2009 at 1:54 PM, ekameleon wrote:
> Hello :)
> Use an argument in the constructor of you class to passed-in the parent
> reference of your display
>
> public function MyDisplay( target:DisplayObjectContainer = null )
> {
>if ( target != null )
>{
> target.addChild( this ) ;
>}
> }
>
> PS : your code isn't valid in the constructor of a DisplayObject the
> "stage"
> and "parent" properties are "null" ! Only in the main class of your
> application this two attributes are not null.
>
> EKA+ :)
>
> 2009/8/17 ACE Flash
>
> > Hi guys,
> >
> > I am curious about if am able to add the DisplayObject into a container
> > without using addChild() method, this class is very simple...
> >
> >
> >
> > 1. package
> > 2. {
> > 3. import flash.display.Sprite;
> > 4. import flash.events.Event;
> > 5.
> > 6. public class MyClass extends Sprite
> > 7. {
> > 8.
> > 9. public function MyClass ()
> > 10. {
> > 11. //addEventListener( Event.ADDED_TO_STAGE , addedHandler );
> > 12. parent.addChild(this);
> > 13. }
> > 14. /*
> > 15. private function addedHandler( e:Event ):void
> > 16. {
> > 17. removeEventListener( Event.ADDED_TO_STAGE , addedHandler );
> > 18.
> > 19. parent.addChild(this); // how could I retrieve the instance name of
> > this"?
> > 20. }
> > 21. */
> > 22. }
> > 23. }
> >
> >
> >
> > I'd like to do something like
> >
> >
> > var do:MyClass = new MyClass();
> > //addChild(do) // added it into displayobject without using this method
> > here
> >
> >
> > Is that possible? any suggestions are welcome :)
> >
> > Thank you
> > ___
> > Flashcoders mailing list
> > [email protected]
> > http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Re: [Flashcoders] How to add a DisplayObject into a container without using addChild() method.
Hello :)
Use an argument in the constructor of you class to passed-in the parent
reference of your display
public function MyDisplay( target:DisplayObjectContainer = null )
{
if ( target != null )
{
target.addChild( this ) ;
}
}
PS : your code isn't valid in the constructor of a DisplayObject the "stage"
and "parent" properties are "null" ! Only in the main class of your
application this two attributes are not null.
EKA+ :)
2009/8/17 ACE Flash
> Hi guys,
>
> I am curious about if am able to add the DisplayObject into a container
> without using addChild() method, this class is very simple...
>
>
>
> 1. package
> 2. {
> 3. import flash.display.Sprite;
> 4. import flash.events.Event;
> 5.
> 6. public class MyClass extends Sprite
> 7. {
> 8.
> 9. public function MyClass ()
> 10. {
> 11. //addEventListener( Event.ADDED_TO_STAGE , addedHandler );
> 12. parent.addChild(this);
> 13. }
> 14. /*
> 15. private function addedHandler( e:Event ):void
> 16. {
> 17. removeEventListener( Event.ADDED_TO_STAGE , addedHandler );
> 18.
> 19. parent.addChild(this); // how could I retrieve the instance name of
> this"?
> 20. }
> 21. */
> 22. }
> 23. }
>
>
>
> I'd like to do something like
>
>
> var do:MyClass = new MyClass();
> //addChild(do) // added it into displayobject without using this method
> here
>
>
> Is that possible? any suggestions are welcome :)
>
> Thank you
> ___
> Flashcoders mailing list
> [email protected]
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
>
___
Flashcoders mailing list
[email protected]
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
