Re: [Flashcoders] Array Empowerment

2006-07-27 Thread ryanm

That's the real source of sloppiness, Java has eliminitaed these
discussions by the simple expeditent of requiring that the conditional
resolves to a boolean, nothing wlse will do. THe real question to me
is does AS3 change this behavior?

   Well, the Flash answer to this is that all conditionals are cast to 
boolean, so if(condition) is effectively executed as if(Boolean(condition)), 
which makes it work, but at the same time it makes it easy to be sloppy.


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-27 Thread ryanm

If you want to do some deeper comparison to see if objects in an array
are identical in content but different instances, then I think 'every'
is the proper method to use and you just pass your comparison function
as the argument.

Any thoughts?

   I think you need both. Maybe name this one "same" (or "sameAs") and the 
other one "equal" (I'd add the s: "equals"), because what the strict 
comparison is really doing is saying that this is a reference to the *same* 
object as the one passed as an argument, not that they are equivalent. 
Equivalency really suggests a comparison between different objects, not just 
a check to see if they are the same object. Basically, you need an 
Object.compare function that you can call from this function. That would 
make life much easier, and you could even have it return a tri-state value, 
e.g. 0=false (not equivalent), 1=true (equivalent), 2 or -1 or null or 
whatever = duplicate reference (a==b).


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-27 Thread Steven Sacks | BLITZ
Latest and greatest!

http://paste.plone.org/7317
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-27 Thread Steven Sacks | BLITZ
After thinking about it, I believe the eql method is fine how it is and
here's why.

If there is an object in there with the same exact properties, but it's
a different instance of the object, then I don't think it should be a
match.  If it points to the same place in memory (same instance) then it
should match, which is how Flash handles MovieClips, Objects, Classes,
etc. as illustrated in this trivial example:

x = {};
y = x;
trace(x == y);
-- true

x = {};
y = {};
trace(x == y);
-- false

This is as it should be.  If the pointer in the array points to the same
object in memory, the it's a match, otherwise, it's not.

If you want to do some deeper comparison to see if objects in an array
are identical in content but different instances, then I think 'every'
is the proper method to use and you just pass your comparison function
as the argument.

Any thoughts?
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-27 Thread Mark Winterhalder

On 7/27/06, Weldon MacDonald <[EMAIL PROTECTED]> wrote:

That's the real source of sloppiness, Java has eliminitaed these
discussions by the simple expeditent of requiring that the conditional
resolves to a boolean, nothing wlse will do. THe real question to me
is does AS3 change this behavior?


I don't know about AS3, but haXe doesn't allow that kind of
"sloppiness", either. Generally, it beats any AS flavour hands down
when it gets to typing, and those of you who consider such things
important should definitely check out  -- you can easily
learn how to do the same things you can do with AS and then still have
what was a whole new world for me to explore to further improve your
code, especially when typing is concerned.

AS allows if(a.length), that's why I always did it that way and never
felt bad about it. Why bother to differ between an undefined length
property and one that is 0 while iterating over an array that itself
can contain objects of any kind, potentially of mixed types, and I
having to trust an unsafe cast if I don't want the overhead of
checking the type at runtime?

Just my two cents worth to a potentially endless discussion that might
turn into a flame war à la whether or not to use _root.

Mark
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-27 Thread Weldon MacDonald

That's the real source of sloppiness, Java has eliminitaed these
discussions by the simple expeditent of requiring that the conditional
resolves to a boolean, nothing wlse will do. THe real question to me
is does AS3 change this behavior?

On 7/27/06, ryanm <[EMAIL PROTECTED]> wrote:

> To me it has always seemed more logical to use if this.length == 0 for the
> very reason of explicitness that you stated; and thus, using the
> alternative !this.length was less enticing. I speculated (wrongly) after
> reading your post that there might be some sort of speed optimization
> inherent to checking if something is false than actually checking for a
> specific length defined explicitly in your code. I don't know why I
> thought that, and obviously I am wrong for the various reasons stated
> earlier.
>
Further, !this.length is very likely slower. Conditions are meant to
resolve to a boolean, but the implicit cast is to a string, which means
walking the prototype to find the property, and if it exists (!=undefined),
casting it to a string, and then recasting it to a boolean. Meanwhile,
this.length==0 resolves directly to a boolean, and, as such, should be a bit
faster. It wouldn't be a noticable difference in speed in a single
condition, but in a recursive loop where it might be evaluated thousands of
times, it could make a significant difference.

ryanm

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com




--
Weldon MacDonald
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-27 Thread ryanm
To me it has always seemed more logical to use if this.length == 0 for the 
very reason of explicitness that you stated; and thus, using the 
alternative !this.length was less enticing. I speculated (wrongly) after 
reading your post that there might be some sort of speed optimization 
inherent to checking if something is false than actually checking for a 
specific length defined explicitly in your code. I don't know why I 
thought that, and obviously I am wrong for the various reasons stated 
earlier.


   Further, !this.length is very likely slower. Conditions are meant to 
resolve to a boolean, but the implicit cast is to a string, which means 
walking the prototype to find the property, and if it exists (!=undefined), 
casting it to a string, and then recasting it to a boolean. Meanwhile, 
this.length==0 resolves directly to a boolean, and, as such, should be a bit 
faster. It wouldn't be a noticable difference in speed in a single 
condition, but in a recursive loop where it might be evaluated thousands of 
times, it could make a significant difference.


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-27 Thread Giles Taylor
How about setting it up on www.osflash.org? 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Steven
Sacks | BLITZ
Sent: 26 July 2006 23:04
To: Flashcoders mailing list
Subject: RE: [Flashcoders] Array Empowerment

It's not done yet. I've identified some bugs in certain functions and
I'm also optimizing it still with everyone's help.  Don't want to jump
the gun too quick until it's absolutely ready.  :)

I think once it's ready, though, SVN would be a great place to keep this
open source project.

BLITZ | Steven Sacks - 310-551-0200 x209


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flashcoders- 
> [EMAIL PROTECTED] On Behalf Of Chris Hill
> Sent: Wednesday, July 26, 2006 2:56 PM
> To: Flashcoders mailing list
> Subject: Re: [Flashcoders] Array Empowerment
> 
> Done! :D
> 
> http://ubergeek.tv/XArray/XArray.as
> 
> I'll put it up there from now on instead of spamming people's inboxes 
> more.
> 
> -C
> 
> Steven Sacks | BLITZ wrote:
> 
> >Chris,
> >
> >You rock!  How about calling it PowerArray or XArray instead.  :)
> >
> >-Steven
> >
> >BLITZ | Steven Sacks - 310-551-0200 x209
> >
> >___
> >Flashcoders@chattyfig.figleaf.com
> >To change your subscription options or search the archive:
> >http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> >Brought to you by Fig Leaf Software
> >Premier Authorized Adobe Consulting and Training 
> >http://www.figleaf.com http://training.figleaf.com
> >
> >
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> 
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training 
> http://www.figleaf.com http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training http://www.figleaf.com
http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread js



Steven Sacks | BLITZ wrote:

As a relative newcomer to Actionscript, I have found the entirety of
this thread very useful. I want to thank all of you for sharing this
code, as well as providing a considerable amount of insight to those
of us lurking in the shadows.


Glad to hear it.

 

I was fairly surprised to see that if(this.length == 0) is considered
sloppy opposed to (!this.length); conjointly, I had no idea that
iterating through an array in the way you described was bad practice
either. I'm sure I've done it quite a few times myself, unaware of the
consequences.


The opposite.  if (this.length == 0) is not sloppy code because it is
explicitly stating what you are expecting, versus accepting anything
that resolves as false in Flash, which includes 0, false, null and
undefined.  You are being strict about what you expect and your code
will be easier to debug because of it, and you will be a stronger
programmer because you are well disciplined and don't take shortcuts
which could potentially come back to haunt you.



Thanks for clearing this up. You didn't really indicate a reason 
between both methods when you said "I always try to write as careful 
code as possible to avoid the oh so enticing opportunities flash 
provides for sloppy coding. Things like if (!this.length) versus if 
(this.length == 0)...", so I wasn't sure which you were referring to 
as the sloppy or correct way.


To me it has always seemed more logical to use if this.length == 0 for 
the very reason of explicitness that you stated; and thus, using the 
alternative !this.length was less enticing. I speculated (wrongly) 
after reading your post that there might be some sort of speed 
optimization inherent to checking if something is false than actually 
checking for a specific length defined explicitly in your code. I 
don't know why I thought that, and obviously I am wrong for the 
various reasons stated earlier.






It would be very beneficial for those of us who are not up to such
(relatively) meticulous levels of coding practice if there was some
sort of resource which enumerated a list of best coding practices when
optimizing for speed--something along the lines of the similarly
titled article in the flash documentation but aimed at the
"middle-class" coder.


I know I don't have time to do this, and I've had to do my own research
over the years to find out this information, and that's fine by me
because it has made me a more resourceful developer.  For loop speed has
been covered numerous times throughout the life of this mailing list and
searching the archives will shed light on lots of different things (use
google to search the archives, the built-in Flashcoders archive search
is broken).


I wasn't asking you to create this resource, just simply stating the 
fact that such would be considerably valuable to many. It might also 
eliminate some of the frequent and routine questions that bother some 
of you so frequently ;).


Searching through the archives is a great thing--predicating one 
actually knows what to search for. In my humble opinion there is much 
more to be said for a unified, centralized, and cohesive source of 
information that has been peer reviewed and updated collectively.


While useful, the archives suffer from discontinuity by the very 
nature of this platform. A mailing list is intrinsically disconnected; 
each post is like a puzzle piece to a much larger concept which 
may--or may not--be accurate, dated, and/or relevant at all to your 
problem at hand. Yet, in order to derive any utility at all, you are 
still faced with the task of assembling the puzzle.


As a sound engineer, graphic artist, photographer, writer, and more 
recently a developer, I don't have the enormous amount of time that I 
would like to wade through mountains of posts in order to arrive at a 
very specific destination. It is not efficient nor realistic to expect 
people to drudge through a pile of loose un-scrutinized data that is 
growing at an exponential rate.


This is just my opinion though.



And besides, if I say to you that this is the fastest for loop (but not
the fastest loop in Flash):

for (var i = len; --i -(-1); ) {}

You're going to ask why, especially given its funky syntax. Yes, it's a
for loop with only two parameters instead of three and the compiler has
no problem with it.  The answer to why is explained by the guys who
wrote Flasm.  If you want to learn more about how the Flash player works
and how to really optimize your code, check out Flasm.

Performance enchancers like putting the more likely result first in an
if statement, the fastest possible loop while(--a -(-1)), etc. are
explained by how Flash compiles your Actionscript into bytecode.

Anyway, good luck!


This sounds interesting; and I will surely look into it. I might even 
create a document fully explaining the issues I encounter, for which I 
would love to get any collaborative input from anyone on this list 
when the time comes.


Thank 

RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> As a relative newcomer to Actionscript, I have found the entirety of
> this thread very useful. I want to thank all of you for sharing this
> code, as well as providing a considerable amount of insight to those
> of us lurking in the shadows.

Glad to hear it.

 
> I was fairly surprised to see that if(this.length == 0) is considered
> sloppy opposed to (!this.length); conjointly, I had no idea that
> iterating through an array in the way you described was bad practice
> either. I'm sure I've done it quite a few times myself, unaware of the
> consequences.

The opposite.  if (this.length == 0) is not sloppy code because it is
explicitly stating what you are expecting, versus accepting anything
that resolves as false in Flash, which includes 0, false, null and
undefined.  You are being strict about what you expect and your code
will be easier to debug because of it, and you will be a stronger
programmer because you are well disciplined and don't take shortcuts
which could potentially come back to haunt you.


> It would be very beneficial for those of us who are not up to such
> (relatively) meticulous levels of coding practice if there was some
> sort of resource which enumerated a list of best coding practices when
> optimizing for speed--something along the lines of the similarly
> titled article in the flash documentation but aimed at the
> "middle-class" coder.

I know I don't have time to do this, and I've had to do my own research
over the years to find out this information, and that's fine by me
because it has made me a more resourceful developer.  For loop speed has
been covered numerous times throughout the life of this mailing list and
searching the archives will shed light on lots of different things (use
google to search the archives, the built-in Flashcoders archive search
is broken).

And besides, if I say to you that this is the fastest for loop (but not
the fastest loop in Flash):

for (var i = len; --i -(-1); ) {}

You're going to ask why, especially given its funky syntax. Yes, it's a
for loop with only two parameters instead of three and the compiler has
no problem with it.  The answer to why is explained by the guys who
wrote Flasm.  If you want to learn more about how the Flash player works
and how to really optimize your code, check out Flasm.

Performance enchancers like putting the more likely result first in an
if statement, the fastest possible loop while(--a -(-1)), etc. are
explained by how Flash compiles your Actionscript into bytecode.

Anyway, good luck!

-Steven





___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
I'm not saying I haven't (or don't continue to) use if (!this.length),
but false is not the same as 0, nor is it the same as null or undefined
and they are important distinctions to make.  It's true that all of
those return true for not, but in more strictly typed languages this can
be problematic.

If you do a check for this.length == 0, you are eliminating the
possibility of a true result for undefined (or null), which is what
would happen if you pass an object where an array or string is intended.
If you can't strict type the argument because it needs to accept either
a String OR an Array, it means you have to strict type it using Object
(which in Flash means typing it is pointless, since everything is an
Object).  Doing so means you can return true for (!this.length) with an
object, even if your code after thinks it has an empty array or string.
And what if your object has a length property?  Yikes.

The reason it's sloppy is because debugging it can become painful later
on when it's buried in thousands of lines of code.  If your code is
tighter and stricter and you don't take shortcuts that Flash lets you
take due to its loosely typed language, you're more likely to write
better code because you're disciplined to do so, and debugging will go
much more easily.  Also, if new players become more strict, old
shortcuts like (!this.length) may break.

Flash programmers can develop "bad habits" as a result of Flash's
loosely based typing.  I'm just saying it's not a bad thing to reel it
in and save yourself from potential debugging issues down the road, and
make it easier if you ever intend on learning a lower level language.
:)


BLITZ | Steven Sacks - 310-551-0200 x209

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Grant Cox
I wouldn't agree that either if(this.length == 0) or iterating over 
object keys is sloppy practice, for standard application development.  
When creating a class library that needs to be bulletproof, as they are 
doing with these Array extensions, you should be more careful.


Specifically, checking if(!this.length) is good if length may be 
undefined, but what about if some crazy person sets length to a string?  
Iterating over object/array keys is fine, throwing an error because you 
find an unexpected key is not (particularly in core library code, not 
application code).


I too would like to commend you guys for sharing this code - it will 
certainly be quite useful in future projects.


Regards,
Grant Cox


js wrote:
As a relative newcomer to Actionscript, I have found the entirety of 
this thread very useful. I want to thank all of you for sharing this 
code, as well as providing a considerable amount of insight to those 
of us lurking in the shadows.


I was fairly surprised to see that if(this.length == 0) is considered 
sloppy opposed to (!this.length); conjointly, I had no idea that 
iterating through an array in the way you described was bad practice 
either. I'm sure I've done it quite a few times myself, unaware of the 
consequences.


It would be very beneficial for those of us who are not up to such 
(relatively) meticulous levels of coding practice if there was some 
sort of resource which enumerated a list of best coding practices when 
optimizing for speed--something along the lines of the similarly 
titled article in the flash documentation but aimed at the 
"middle-class" coder.


I don't think I would be the only individual to appreciate such a 
resource; if anyone knows of something similar, do share!


Joseph


Steven Sacks | BLITZ wrote:

DataProvider is not secretly decorating things, BUT something

somewhere

in the V2 stuff is iterating over the array object itself, and is
silently blowing up when it finds these extra functions. I've had a
similar problem when some third party code was adding a function to
object.prototype, and the WebService object took a dump (it iterates
over a hash object and sees something weird and throws an error).


This is an example of poor coding by MM's component writers.  You
shouldn't be iterating through enumerable arrays using for (var a in
this) because you're going to pick up all the methods of the Array
object, as well.  It's just sloppy coding due to how loose Flash is with
its typing.  I always try to write as careful code as possible to avoid
the oh so enticing opportunities flash provides for sloppy coding.
Things like if (!this.length) versus if (this.length == 0)...

However, using ASSetPropFlags is the best solution to hide functions so
they don't appear when you iterate through an Array object.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com



___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com



___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Mike
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of js
> Sent: Wednesday, July 26, 2006 7:01 PM
> To: Flashcoders mailing list
> Subject: Re: [Flashcoders] Array Empowerment
> 
> I was fairly surprised to see that if(this.length == 0) is considered 
sloppy opposed to (!this.length);

Err, other way around. (Although I have to admit I've been guilty of the
latter on numerous occasions--blame my C background.)
--
T. Michael Keesey

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread js
As a relative newcomer to Actionscript, I have found the entirety of 
this thread very useful. I want to thank all of you for sharing this 
code, as well as providing a considerable amount of insight to those 
of us lurking in the shadows.


I was fairly surprised to see that if(this.length == 0) is considered 
sloppy opposed to (!this.length); conjointly, I had no idea that 
iterating through an array in the way you described was bad practice 
either. I'm sure I've done it quite a few times myself, unaware of the 
consequences.


It would be very beneficial for those of us who are not up to such 
(relatively) meticulous levels of coding practice if there was some 
sort of resource which enumerated a list of best coding practices when 
optimizing for speed--something along the lines of the similarly 
titled article in the flash documentation but aimed at the 
"middle-class" coder.


I don't think I would be the only individual to appreciate such a 
resource; if anyone knows of something similar, do share!


Joseph


Steven Sacks | BLITZ wrote:

DataProvider is not secretly decorating things, BUT something

somewhere

in the V2 stuff is iterating over the array object itself, and is
silently blowing up when it finds these extra functions. I've had a
similar problem when some third party code was adding a function to
object.prototype, and the WebService object took a dump (it iterates
over a hash object and sees something weird and throws an error).


This is an example of poor coding by MM's component writers.  You
shouldn't be iterating through enumerable arrays using for (var a in
this) because you're going to pick up all the methods of the Array
object, as well.  It's just sloppy coding due to how loose Flash is with
its typing.  I always try to write as careful code as possible to avoid
the oh so enticing opportunities flash provides for sloppy coding.
Things like if (!this.length) versus if (this.length == 0)...

However, using ASSetPropFlags is the best solution to hide functions so
they don't appear when you iterate through an Array object.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com



___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> DataProvider is not secretly decorating things, BUT something
somewhere
> in the V2 stuff is iterating over the array object itself, and is
> silently blowing up when it finds these extra functions. I've had a
> similar problem when some third party code was adding a function to
> object.prototype, and the WebService object took a dump (it iterates
> over a hash object and sees something weird and throws an error).

This is an example of poor coding by MM's component writers.  You
shouldn't be iterating through enumerable arrays using for (var a in
this) because you're going to pick up all the methods of the Array
object, as well.  It's just sloppy coding due to how loose Flash is with
its typing.  I always try to write as careful code as possible to avoid
the oh so enticing opportunities flash provides for sloppy coding.
Things like if (!this.length) versus if (this.length == 0)...

However, using ASSetPropFlags is the best solution to hide functions so
they don't appear when you iterate through an Array object.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Mark Winterhalder

On 7/27/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote:

> Also, why not use strict inequality to compare the values?

For example?


eql().

0 != "0" // false
0 !== "0" // true

BTW, I added it in compact in my last post and forgot to mention it,
didn't want to just sneak it in.

Mark
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> I just had a look at eql (equality) because of the recursion there and
> actually I'm not sure it should be there at all. By that logic you
> would have to compare the properties of objects, too, which would
> raise questions about recursion depth. 

You're right.  Object == Object doesn't work.  Hm...

It seems that the eql method should work that way though - all the way
through, I mean.  It should check to see if the pointers are equal.
Since Arrays just hold pointers, it should technically just detect if
the pointers are the same by their position in memory, something
unavailable to us in AS.

A few of the other methods rely on eql, so a solution has to be found.

> Also, why not use strict inequality to compare the values?

For example?
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Mark Winterhalder

On 7/27/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote:

Here are the methods that use push, btw:

compact
deleteAll
deleteIf
filter
indexes
map
uniq


Below.

Is there something like a test yet so I can make sure I didn't
accidentally introduced some errors?

Mark







function compact() {
var i = -1;
var n = this.length;
var r = [];
var index = 0;
for (var a = 0; a < n; a++) {
var e = this[a];
if (e !== null && e !== undefined) {
r[ index++ ] = e;
}
}
};

function deleteAll(obj) {
var n = this.length;
var r = [];
var index = 0;
if (!(obj instanceof Array)) {
for (var a = 0; a < n; a++) {
var e = this[a];
if (e == obj) r[ index++ ] = e;
}
} else {
for (var a = 0; a < n; a++) {
var e = this[a];
if (!e.eql(obj)) r[ index++ ] = e;
}   
}
this.replicate(r);
};

function deleteIf(block) {
var r = [];
var n = this.length;
var index = 0;
for (var a = 0; a < n; a++) {
var e = this[a];
if (!block(e)) {
r[ index++ ] = e;
}
}
this.replicate(r);
};


function filter(block) {
var r = [];
var n = this.length;
var index = 0;
for (var a = 0; a < n; a++) {
var e = this[a];
if (block(e)) r[ index++ ] = e;
}
return r;
};

function indexes() {
var r = [];
var l = arguments.length;
var n = this.length;
var index = 0;
for (var a = 0; a < l; a++) {
var e = arguments[a];
if (e > -1 && e < n) {
r[ index++ ] = this[e];
} else {
r[ index++ ] = undefined;
}
}
return r;
};

function map(block) {
var r = [];
var n = this.length;
var index = 0;
for (var a = 0; a < n; a++) {
r[ index++ ] = block(this[a]);
}
return r;
};

function uniq() {
var r = [];
var l = this.length;
var index = 0;
for (var a = 0; a < l; a++) {
var e = this[a];
if (!r.has(e)) r[ index++ ] = e;
}
return r;
};

<<<
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Mark Winterhalder

On 7/27/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote:

http://paste.plone.org/7081


I just had a look at eql (equality) because of the recursion there and
actually I'm not sure it should be there at all. By that logic you
would have to compare the properties of objects, too, which would
raise questions about recursion depth. Maybe have a deepEquality
method that takes the depth as an argument?

Also, why not use strict inequality to compare the values?

Mark
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> Remove and delete aren't synonymous, and I think remove is much better
> suited to what is happening in the function. Without looking at the
> function
> or reading any documentation, I would assume that a delete method
> destroyed
> the object, not just removed it from the array. An Array.delete
function
> should really delete the array.

Fair enough.  I'll concede the point and rename the method to remove.
:)


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread ryanm

Remove and delete are essentially synonymous.

Backspace and Delete, Enter and Return...which is right?  :)

   Well, if you want to get into the semantics, return and enter are 
different, and backspace and delete are different. Enter just means 
"execute", while return actually means "carriage return + line feed". 
Backspace means "move the cursor back a space, deleting any character that 
may be in that position", while delete means "delete the character in the 
current cursor position".


   Remove and delete aren't synonymous, and I think remove is much better 
suited to what is happening in the function. Without looking at the function 
or reading any documentation, I would assume that a delete method destroyed 
the object, not just removed it from the array. An Array.delete function 
should really delete the array.


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread ryanm

every and some come from php.

   Php is probably a bad place to take naming conventions from. It is a 
prime example of the mess that open source can cometimes bring, considering 
they have split and join *and* explode and implode, not to mention about 2 
dozen different functions that do the same things to strings. There is no 
agreed-upon naming convention or standard in php, and the resulting mess has 
a cobbled-together and almost impossible to predict naming convention (if 
you could call it that), so I would recommend looking to a stricter and more 
well established language for a naming convention, like Java or even C++.


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
http://paste.plone.org/7081

Meh, silly bug with indices now that it's just functions.  Removed for
now.

-s
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
http://paste.plone.org/7080

I've fixed some bugs, implemented flatten4, and also changed the methods
to just function() calls for easier implementation into the great mixin
class that Chris wrote.  I also assigned this[a] to a variable 'e' where
this[a] is used more than once in a loop.  Removing the use of push() is
next on the list but before I go through and do all that, perhaps some
of these methods could be optimized more like we did with flatten.

Here are the methods that use push, btw:

compact
deleteAll
deleteIf
filter
indexes
map
uniq

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
It's not done yet. I've identified some bugs in certain functions and
I'm also optimizing it still with everyone's help.  Don't want to jump
the gun too quick until it's absolutely ready.  :)

I think once it's ready, though, SVN would be a great place to keep this
open source project.

BLITZ | Steven Sacks - 310-551-0200 x209


> -Original Message-
> From: [EMAIL PROTECTED] [mailto:flashcoders-
> [EMAIL PROTECTED] On Behalf Of Chris Hill
> Sent: Wednesday, July 26, 2006 2:56 PM
> To: Flashcoders mailing list
> Subject: Re: [Flashcoders] Array Empowerment
> 
> Done! :D
> 
> http://ubergeek.tv/XArray/XArray.as
> 
> I'll put it up there from now on instead of spamming people's inboxes
> more.
> 
> -C
> 
> Steven Sacks | BLITZ wrote:
> 
> >Chris,
> >
> >You rock!  How about calling it PowerArray or XArray instead.  :)
> >
> >-Steven
> >
> >BLITZ | Steven Sacks - 310-551-0200 x209
> >
> >___
> >Flashcoders@chattyfig.figleaf.com
> >To change your subscription options or search the archive:
> >http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> >
> >Brought to you by Fig Leaf Software
> >Premier Authorized Adobe Consulting and Training
> >http://www.figleaf.com
> >http://training.figleaf.com
> >
> >
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> 
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill

Done! :D

http://ubergeek.tv/XArray/XArray.as

I'll put it up there from now on instead of spamming people's inboxes more.

-C

Steven Sacks | BLITZ wrote:


Chris,

You rock!  How about calling it PowerArray or XArray instead.  :)

-Steven

BLITZ | Steven Sacks - 310-551-0200 x209

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Ok, I'll go through and make those changes to every loop with this[a] is
referenced more than once.


BLITZ | Steven Sacks - 310-551-0200 x209

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Chris,

You rock!  How about calling it PowerArray or XArray instead.  :)

-Steven

BLITZ | Steven Sacks - 310-551-0200 x209

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill
DataProvider is not secretly decorating things, BUT something somewhere 
in the V2 stuff is iterating over the array object itself, and is 
silently blowing up when it finds these extra functions. I've had a 
similar problem when some third party code was adding a function to 
object.prototype, and the WebService object took a dump (it iterates 
over a hash object and sees something weird and throws an error).


Anyway, the solution is to call ASSetPropFlags on the function so that 
it is hidden. I heavily modified your class to make it more AS2 
friendly, hope you don't mind! To use this class either call (once) :


ArrayEmpowerment.init();

or if you just want to decorate just one object:

ArrayEmpowerment.mixin(myobject);

I also check to see if the function exists before decorating and warn. 
This way we'll know if there is a decorator conflict.


class ArrayEmpowerment extends Object{
  
   private static var initialized:Boolean = false;

   private static var mixins:ArrayEmpowerment = new ArrayEmpowerment();
   private static var mixInProps:Array = 
["any","clear","collect","compact","count","deleteAll","deleteAt","deleteIf","duplicate","each","eachIndex"
   
,"eql","every","fill","filter","flatten","has","index","indexes","last","map","nitems","replicate","reverseEach"

   ,"lastIndexOf","uniq","sum","mean","min","max"];
  
  
   // inherent properties of array

   var length : Number;
   var splice : Function;
   var slice : Function;
   var sortOn : Function;
   var reverse : Function;
   var sort : Function;
  
   /**
* Empowered Array - Decorates the Array class with all the 
functions of this class.

*/
   public static function init(){
   if(initialized){ return; };
   initialized = true;
  
   // take all methods/props from our template object

   // and put them on the prototype.
   mixin(Array.prototype);
   }
  
   /**

* Instead of calling init, you may call mixin on an object, and it will
* decorate the object only, instead of Array.prototype.
*/
   public static function mixin(obj:Object){
   var m = mixInProps;
   var l = m.length;

   for (var i=0; i   trace("WARNING Function:"+m[i]+" already exists! 
Aborting mixin.");

   }else{
   obj[m[i]] = mixins[m[i]];
   _global.ASSetPropFlags(obj, m[i],1);
   }
   }
   }

   // Runs a function on every item in the array
   // Returns true if the function returns true for any one item
   function any(block) {
   var a = this.length;
   while (--a -(-1)) {
   if (block(this[a])) return true;
   }
   return false;
   };
   // Removes all elements from Array
   function clear() {
   this.length = 0;
   };
   // Invoking block once for every element, passing each element as a
   // parameter to block
   // The result of block is used as the given element in the array
   function collect(block) {
   var n = this.length;
   for (var a = 0; a < n; a++) {
   this[a] = block(this[a]);
   }
   };
   // Removes all null and undefined elements from Array
   function compact() {
   var i = -1;
   var n = this.length;
   var r = [];
   for (var a = 0; a < n; a++) {
   if (this[a] != null && this[a] != undefined) {
   r.push(this[a]);
   }
   }
   };
   // Returns the number of obj found in the Array.
   function count(obj) {
   var c = 0;
   var a = this.length;
   if (obj instanceof Array) {
   while (--a -(-1)) {
   if (this[a].eql(obj)) c++;
   }
   } else {
   while (--a -(-1)) {
   if (this[a] == obj) c++;
   }
   }
   return c;
   };
   // Deletes items from the Array that are equal to obj
   function deleteAll(obj) {
   var n = this.length;
   var r = [];
   if (!(obj instanceof Array)) {
   for (var a = 0; a < n; a++) {
   if (this[a] == obj) r.push(this[a]);
   }
   } else {
   for (var a = 0; a < n; a++) {
   if (!this[a].eql(obj)) r.push(this[a]);
   }   
   }

   this.replicate(r);
   };
   // Deletes the element at the specified index, returning that element,
   // or undefined if the index is out of range
   function deleteAt(i) {
   if (i < this.length && i > -1) return this.splice(i, 1)[0];
   return undefined;
   };
   // Deletes every element of Array for which block evaluates to true
   function deleteIf(block) {
   var r = [];
   var n = this.length;
   for (var a = 0; a < n; a++) {
   if (!block(this[a])) {
   r.push(this[a]);
   }
   }
   this.replicate(r);
   };
   // Returns a copy of the array
   function duplicate() {
   var r = [];
   var a = this.length;
   while (--a -(-1)) {
   r[a] = this[a];
   }
   return r;
   };

Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill
Hmmm...it looks as though there are some name conflicts or something 
between MM v2 Array mixins and your functions. I've got a DataGrid, and 
as soon as I add the ArrayEmpowerment class, the data grid stops 
working. I'm assuming that DataProvider's adding some methods with the 
same names as your class.


I'm going to debug this right now...perhaps X-ray will prove useful here? :D

Chris
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Ammon Lauritzen

On 7/26/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote:

Backspace and Delete, Enter and Return...which is right?  :)


^H
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Mark Winterhalder

On 7/26/06, Steven Sacks | BLITZ <[EMAIL PROTECTED]> wrote:

Keep the feedback coming!


Hi Steve,

very nice -- I went back to the flattening thing, the current test is
at . I'm getting:

iterative:1453
new recursive: 1678
recursive: 1738

I'm posting this here because the improvement in "new recursive"
applies for some other functions, too. It's very simple, whenever you
use this[a] more than once in a loop, store it in a local var. It's a
tiny thing with a measurable effect, as you can see above.

Mark
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> There must be equivalent Java functions somewhere (and ActionScript is
> far more akin to Java than PHP or Ruby).

I think every and any are fine, to be honest.


> But, as pointed out before, ActionScript is far more akin to Java,
where
> "equals" is something just about every single object has. Furthermore,
> some Flash objects (e.g., Point), already use "equals". Finally, "eql"
> looks a lot like "leq".

What's leq?


> "Deleting" means you are utterly destroying the object
> --essentially forcing garbage collection. 

Ah, well this is where the point I made to Mike comes into play.  I'm
not destroying an element OF the Array, I'm deleting an element FROM the
Array.  Array.delete means delete an element of the Array because that's
the scope of the delete method - it belongs to the Array and refers to
the collection of objects, not the objects themselves.

Permit me a Ted Stevens moment, if you will.  An Array is a box that is
self-aware of its contents and nothing else.  If you remove an item from
the box, from the Box's point of view, that item no longer exists - it's
been deleted from the Box.

Remove and delete are essentially synonymous.

If I delete (or remove, as you say) an element from an Array, the Array
takes up less memory, hence garbage collection is doing its job and I am
utterly destroying the pointer's presence in the Array (not the pointer
itself).  I'm chocking this up to a fundamental difference of opinion
about the theoretical (philosophical?) relationships of Objects in an
OOP design pattern.

Backspace and Delete, Enter and Return...which is right?  :)


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Ah.  Thanks!  I updated the list.

Ok, I'm getting back to work on String extension, the next in the
series.  

Keep the feedback coming!

-Steven

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Mike
> > - "nitems" looks like "number of items" (i.e., "length"); why not
> > "numSetItems" or "countSetItem"?
>
> Yeah, I didn't think it was very descriptive either, but it returns
the
> number of non null/undefined items in the array (which, at the moment,
I
> don't see as very useful, hehe).  Perhaps it could be notNullCount()?

Yes, even better than my suggestions (or "countNotNull").

> This method actually inspires me to create a more useful method that I
> think is missing: count.

Nice.

> > - "some" -- maybe "forSome", or "exists"? (Also, "every" makes more
> > sense to me as "forAll".)
>
> every and some come from php.  But you bringing this up made me think
> about it, and I've concluded that 'any' is a more descriptive method
> name (and one less character to type!). 'any' and 'every' go together
> well (like chocolate and peanut butter).  I've renamed 'some' to
'any'.

In mathematics these are the quantifiers written as an upside-down "A"
and a backwards "E", respectively. They are usually read (and often
written) as "for all" and "[there] exists" or "for some"--hence my
suggestions.

There must be equivalent Java functions somewhere (and ActionScript is
far more akin to Java than PHP or Ruby).

> > - "eql" -- "equals" is far more standard
>
> eql is what is used in Ruby, while Java uses equals.  I don't know if
> there's a clear standard.  I like Ruby.  I think it's a great
language.
> I have no problem with shaving a few chars off for quicker typing,
> especially if "equals" ever enters into the language.  eql is more
> likely to not conflict with anything.

But, as pointed out before, ActionScript is far more akin to Java, where
"equals" is something just about every single object has. Furthermore,
some Flash objects (e.g., Point), already use "equals". Finally, "eql"
looks a lot like "leq".

> > - "include" is pretty close to a reserved word
>
> You're right.  I've renamed it 'has', which I think is perfect, and,
> coincidentally, still maintains alphabetical order without having to
> move it.  :)

Nice.

> > - the "delete" functions don't so much "delete" (i.e., totally
destroy)
> > as "remove" or "strip".
>
> They do delete - from the Array.  This method belongs to the Array
> class.  Hence, it's doing exactly what it says and what you expect -
> deleting an element from the Array.  Once you delete it from the
Array,
> it's no longer in the Array.  It's not Object.delete, it's
Array.delete.
> 
> Delete is the original name of the method in Ruby, but delete is a
Flash
> native method and cannot be assigned to a function.  So, I've used
> deleteAll, deleteAt and deleteIf.

There is no Object.delete or Array.delete, nor can there be, since
"delete" is a keyword--not a native method (like, say, "trace" or
"setInterval"), but part of the language itself (like "new"--same as in
C and Java and PHP). "Deleting" means you are utterly destroying the
object--essentially forcing garbage collection. "Removing" means you are
taking it out of the array (but it might still be referenced somewhere
else). I think you should only use "delete" (or "destroy") as part of
the name if you are actually forcing deletion, not if you are just
removing a reference.

In short, I don't think it's a good idea to use Ruby or PHP conventions
in ActionScript. Look to other ActionScript conventions first, then look
to Java conventions.

Niggling points, I know, but legible code is worth some thought, I
think.
--
T. Michael Keesey

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> Quick optimization - Pulled the if instanceof Array out of the loop:

And again:

// Returns the index of the first object in Array such that the object
== obj.
// Returns undefined if no match is found
Array.prototype.index = function(obj) {
var a = this.length;
if (!(this[a] instanceof Array)) {
while (--a -(-1)) {
if (this[a] == obj) return a;
}
} else {
while (--a -(-1)) {
if (this[a].eql(obj)) return a;
}
}
return undefined;
};
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill

Darn, I wasn't fast enough to get this into rev 3 :)

Array.prototype.sum = function() {
   var x = 0;
   var a = this.length;
   while (--a -(-1)) {
   var n = Number(this[a]);
   if (!isNaN(n)) {
   x += n;
   } else {
   return undefined;
   }
   }
   return x;
};


While you were casting to Number for the test, when you actually added 
you were adding the initial value. This meant strings were concatenated 
instead of added.


Peace
C
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Quick optimization - Pulled the if instanceof Array out of the loop:

Array.prototype.lastIndexOf = function(obj) {
var a = this.length;
if (!(this[a] instanceof Array)) {
while (--a -(-1)) {
if (this[a] == obj) return a;   
}
} else {
 while (--a -(-1)) {
if (this[a].eql(obj)) return a; 
}
}
return undefined;
};


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Version 3 - Keep those revisions, suggestions, comments coming!
---
// Empowered Array
// Runs a function on every item in the array
// Returns true if the function returns true for any one item
Array.prototype.any = function(block) {
var a = this.length;
while (--a -(-1)) {
if (block(this[a])) return true;
}
return false;
};
// Removes all elements from Array
Array.prototype.clear = function() {
this.length = 0;
};
// Invoking block once for every element, passing each element as a
parameter to block
// The result of block is used as the given element in the array
Array.prototype.collect = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
this[a] = block(this[a]);
}
};
// Removes all null and undefined elements from Array
Array.prototype.compact = function() {
var i = -1;
var n = this.length;
var r = [];
for (var a = 0; a < n; a++) {
if (this[a] != null && this[a] != undefined) {
r.push(this[a]);
}
}
};
// Returns the number of obj found in the Array.
Array.prototype.count = function(obj) {
var c = 0;
var a = this.length;
if (obj instanceof Array) {
while (--a -(-1)) {
if (this[a].eql(obj)) c++;
}
} else {
while (--a -(-1)) {
if (this[a] == obj) c++;
}
}
return c;
};
// Deletes items from the Array that are equal to obj
Array.prototype.deleteAll = function(obj) {
var n = this.length;
var r = [];
if (!(obj instanceof Array)) {
for (var a = 0; a < n; a++) {
if (this[a] == obj) r.push(this[a]);
}
} else {
for (var a = 0; a < n; a++) {
if (!this[a].eql(obj)) r.push(this[a]);
}   
}
this.replicate(r);
};
// Deletes the element at the specified index, returning that element,
or undefined if the index is out of range
Array.prototype.deleteAt = function(i) {
if (i < this.length && i > -1) return this.splice(i, 1)[0];
return undefined;
};
// Deletes every element of Array for which block evaluates to true
Array.prototype.deleteIf = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (!block(this[a])) {
r.push(this[a]);
}
}
this.replicate(r);
};
// Returns a copy of the array
Array.prototype.duplicate = function() {
var r = [];
var a = this.length;
while (--a -(-1)) {
r[a] = this[a];
}
return r;
};
// Calls block once for each element in Array, passing that element as a
parameter
Array.prototype.each = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(this[a]);
}
};
// Same as Array.each, but passes the index of the element instead of
the element itself
Array.prototype.eachIndex = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(a);
}
};
// An array is equal to another array if the lengths are equal and each
corresponding element is equal
Array.prototype.eql = function(arr) {
if (arr.length != this.length || !(arr instanceof Array)) {
return false;
} else {
var a = this.length;
while (--a -(-1)) {
if (this[a] instanceof Array) {
if (!this[a].eql(arr[a])) return false;
} else if (this[a] != arr[a]) {
return false;
}
}
}
return true;
};
// Runs block on every item in the array 
// Returns true if the function returns true for every item
Array.prototype.every = function(block) {
var a = this.length;
while (--a -(-1)) {
if (!block(this[a])) return false;
}
return true;
};
// Sets the selected elements of Array (which may be the entire array)
to obj
// A start of undefined is equivalent to zero. 
// A length of undefined is equivalent to Array.length.
Array.prototype.fill = function(obj, start, len) {
if (!start) start = 0;
if (len == undefined) len = this.length;
len = start + len;
if (len > this.length) len = this.length;   
while (--len - (-1) > start) {
this[len] = obj;
}
};
// Runs a function on every item in the array
// Returns an array of all items for which the function returns true.
Array.prototype.filter = function(block) {
var r = [];
var n = this.length;
for (va

RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Yes I see it.  Thanks for pointing that out.

Yes, the isNaN(Number(this[a])) check will convert string numbers to
numbers and that's a great benenfit in a language where strict typing is
bogus.

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
> Those are great additions. You need a duplicate_deep and a
> replicate_deep, though. Right now, any obejcts stored in the array
will be
> references in the new array. A _deep method would make copies of those
> too, recursively caling Array.duplicate, or Object.duplicate. ;-)

I'm not sure this is an issue, and here's why.  An Array is an
enumerable hash of references.  If I'm duplicating the Array, I'm not
duplicating the references, I'm duplicating the container of the
references.  Array.duplicate duplicates the Array.

What you're describing is not really a method of Array, and blurs the
line between an Array and the contents of an Array.  Plus, I don't see
how what you're describing could really be useful and it seems like a
dangerous notion fraught with potential memory waste/leaks.  :)

And, you can actually write it yourself easily enough with each or
collect.

newArray = oldArray.duplicate();
function dupeObj(o) {
// newObj = duplicate o
return newObj;
}
newArray.collect(dupeObj);

Tada!

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill
I just checked and delete_all did not have 'var a' but just 'a' in the 
loops. No biggie.


I'm not really sure that converting a primitive to an object, then 
testing with isNaN is faster than just using typeof and (if that fails) 
instanceof. But what I do like about it is that it works with numeric 
strings.


Chris
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
Thanks for pointing out the issues with sum.  I think I have found a
decent solution, though I'm not certain of the performance hit.

Array.prototype.sum = function() {
var x = 0;
var a = this.length;
while (--a -(-1)) {
if (!isNaN(Number(this[a]))) {
x += this[a];
} else {
return undefined;
}
}
return x;
};

> Additionally, it would help to have a return statement :D.

Oops! Nice catch.  :)


> Lastly, there were a couple places where you did not use 'var' and the
> compiler caught it when I encapsulated your AS 1 into a class. I'll
post
> if you like.

Where?  I just double-checked. The only place I can think your compiler
might complain is Array.fill, but 'len' is an argument.

-Steven

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: Re: [Flashcoders] Array Empowerment

2006-07-26 Thread John Mark Hawley
One thing about putting these methods into a class -- it would be nice if they 
were a mixin so only Arrays that actually needed the methods got them. (Mixing 
into the Array prototype would add them to all Arrays if a user decided that 
would be worthwhile.)

I occasionally make utility classes (ArrayUtil) and exporter classes 
(ArrayUtilExporter) -- the utility class has methods like:

ArrayUtil.contains( toCheck:Array, item:Object ) :Boolean

and the exporter class is a mixin that adds the ArrayUtil methods to a given 
array.

-mark

> 
> From: Chris Hill <[EMAIL PROTECTED]>
> Date: 2006/07/26 Wed PM 01:20:15 CDT
> To: Flashcoders mailing list 
> Subject: Re: [Flashcoders] Array Empowerment
> 
> Found a couple problems with sum():
> First off, instanceof works with *objects* not primitives, and so you 
> must do:
> 
> var a:Array = new Array(new Number(2),new Number(3),new Number(54),new 
> Number(6),new Number(7),new Number(8),new Number(9));
> 
> instead of say:
> 
> var b:Array = new Array(2,3,54,6,7,8,9);
> 
> So you *have* to check with typeof for primitives, then instanceof for 
> objects. Horrible, I know.
> 
> Additionally, it would help to have a return statement :D.
> 
> Array.prototype.sum = function() {
> var x = 0;
> var a = this.length;
> while (--a -(-1)) {
> var num = this[a];
> if (typeof(num) == "number" || num instanceof Number) {
> x += num;
> } else {
> return undefined;
> }
> }
> return x;
> };
> 
> //Here are the test cases i wrote to verify functionality
> 
> var a:Array = new Array(new Number(2),new Number(3),new Number(54),new 
> Number(6),new Number(7),new Number(8),new Number(9));
> var b:Array = new Array(2,3,54,6,7,8,9);
> var c:Array = new Array(2,new Number(3),new Number(54), 6,7,8,9);
> var d:Array = new Array("2",3,4,new Number(54),6,7,8,9); //should return 
> undefined
> trace(a.sum());
> trace(b.sum());
> trace(c.sum());
> trace(d.sum());
> 
> 
> Lastly, there were a couple places where you did not use 'var' and the 
> compiler caught it when I encapsulated your AS 1 into a class. I'll post 
> if you like.
> 
> Peace
> C
> ___
> Flashcoders@chattyfig.figleaf.com
> To change your subscription options or search the archive:
> http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
> 
> Brought to you by Fig Leaf Software
> Premier Authorized Adobe Consulting and Training
> http://www.figleaf.com
> http://training.figleaf.com
> 

--
John Mark Hawley
The Nilbog Group
773.968.4980 (cell)

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Steven Sacks | BLITZ
I appreciate all feedback on this Array extension.

> Why do the function names have underscores when "camel-humped" names
are
> the customary syntax in ActionScript

It's how Ruby does it and I'm learning Ruby so I guess it just carried
over.  I've changed them to AS formatting.


> Some of the names could be clearer:

All but two of these method names came from the Array classes in Ruby,
php and Java.  If they're good enough for those, they're good enough for
AS.  :)


> - "nitems" looks like "number of items" (i.e., "length"); why not
> "numSetItems" or "countSetItem"?

Yeah, I didn't think it was very descriptive either, but it returns the
number of non null/undefined items in the array (which, at the moment, I
don't see as very useful, hehe).  Perhaps it could be notNullCount()?
This method actually inspires me to create a more useful method that I
think is missing: count.

// Returns the number of obj found in the Array.
Array.prototype.count = function(obj) {
var c = 0;
var a = this.length;
if (obj instanceof Array) {
while (--a -(-1)) {
if (this[a].eql(obj)) c++;
}
} else {
while (--a -(-1)) {
if (this[a] == obj) c++;
}
}
return c;
};


> - "rindex" is a bit confusing

I've renamed it lastIndexOf to match the String method which does the
same thing.


> - "some" -- maybe "forSome", or "exists"? (Also, "every" makes more
> sense to me as "forAll".)

every and some come from php.  But you bringing this up made me think
about it, and I've concluded that 'any' is a more descriptive method
name (and one less character to type!). 'any' and 'every' go together
well (like chocolate and peanut butter).  I've renamed 'some' to 'any'.


> - "eql" -- "equals" is far more standard

eql is what is used in Ruby, while Java uses equals.  I don't know if
there's a clear standard.  I like Ruby.  I think it's a great language.
I have no problem with shaving a few chars off for quicker typing,
especially if "equals" ever enters into the language.  eql is more
likely to not conflict with anything.


> - "include" is pretty close to a reserved word

You're right.  I've renamed it 'has', which I think is perfect, and,
coincidentally, still maintains alphabetical order without having to
move it.  :)


> - the "delete" functions don't so much "delete" (i.e., totally
destroy)
> as "remove" or "strip".

They do delete - from the Array.  This method belongs to the Array
class.  Hence, it's doing exactly what it says and what you expect -
deleting an element from the Array.  Once you delete it from the Array,
it's no longer in the Array.  It's not Object.delete, it's Array.delete.
Delete is the original name of the method in Ruby, but delete is a Flash
native method and cannot be assigned to a function.  So, I've used
deleteAll, deleteAt and deleteIf.


Thanks!

-Steven

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill

Found a couple problems with sum():
First off, instanceof works with *objects* not primitives, and so you 
must do:


var a:Array = new Array(new Number(2),new Number(3),new Number(54),new 
Number(6),new Number(7),new Number(8),new Number(9));


instead of say:

var b:Array = new Array(2,3,54,6,7,8,9);

So you *have* to check with typeof for primitives, then instanceof for 
objects. Horrible, I know.


Additionally, it would help to have a return statement :D.

Array.prototype.sum = function() {
   var x = 0;
   var a = this.length;
   while (--a -(-1)) {
   var num = this[a];
   if (typeof(num) == "number" || num instanceof Number) {
   x += num;
   } else {
   return undefined;
   }
   }
   return x;
};

//Here are the test cases i wrote to verify functionality

var a:Array = new Array(new Number(2),new Number(3),new Number(54),new 
Number(6),new Number(7),new Number(8),new Number(9));

var b:Array = new Array(2,3,54,6,7,8,9);
var c:Array = new Array(2,new Number(3),new Number(54), 6,7,8,9);
var d:Array = new Array("2",3,4,new Number(54),6,7,8,9); //should return 
undefined

trace(a.sum());
trace(b.sum());
trace(c.sum());
trace(d.sum());


Lastly, there were a couple places where you did not use 'var' and the 
compiler caught it when I encapsulated your AS 1 into a class. I'll post 
if you like.


Peace
C
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Chris Hill
Thanks a lot for your array functions. I'm setting these up in a class 
file, and I was thinking that I'd add the functions to the intrinsics. 
But I looked at the intrinsics file for Array.as, and I was a bit 
surprised to learn that Array is dynamic. So is it worth the effort to 
modify the intrinsics?


Thanks
Chris

Steven Sacks | BLITZ wrote:


Here is the next iteration - new and improved.   Again, all comments and
optimizations, including conversations about optimizations, are most
welcome!

// Array Empowerment
// Removes all elements from Array
Array.prototype.clear = function() {
this.length = 0;
};
// Invoking block once for every element, passing each element as a
parameter to block
// The result of block is used as the given element in the array
Array.prototype.collect = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
this[a] = block(this[a]);
}
};
// Removes all null and undefined elements from Array
Array.prototype.compact = function() {
var i = -1;
var n = this.length;
var r = [];
for (var a = 0; a < n; a++) {
if (this[a] != null && this[a] != undefined) {
r.push(this[a]);
}
}
};
// Deletes items from the Array that are equal to obj
Array.prototype.delete_all = function(obj) {
var n = this.length;
var r = [];
if (!(obj instanceof Array)) {
for (a = 0; a < n; a++) {
if (this[a] == obj) r.push(this[a]);
}
} else {
for (a = 0; a < n; a++) {
if (!this[a].eql(obj)) r.push(this[a]);
}   
}
this.replicate(r);
};
// Deletes the element at the specified index, returning that element,
or undefined if the index is out of range
Array.prototype.delete_at = function(i) {
if (i < this.length && i > -1) return this.splice(i, 1)[0];
return undefined;
};
// Deletes every element of Array for which block evaluates to true
Array.prototype.delete_if = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (!block(this[a])) {
r.push(this[a]);
}
}
this.replicate(r);
};
Array.prototype.duplicate = function() {
var r = [];
var a = this.length;
while (--a -(-1)) {
r[a] = this[a];
}
return r;
};
Array.prototype.replicate = function(r) {
this.length = 0;
var a = r.length;
while (--a -(-1)) {
this[a] = r[a];
}
};
// Calls block once for each element in Array, passing that element as a
parameter
Array.prototype.each = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(this[a]);
}
};
// Same as Array.each, but passes the index of the element instead of
the element itself
Array.prototype.each_index = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(a);
}
};
// An array is equal to another array if the lengths are equal and each
corresponding element is equal
Array.prototype.eql = function(arr) {
if (arr.length != this.length || !(arr instanceof Array)) {
return false;
} else {
var a = this.length;
while (--a -(-1)) {
if (this[a] instanceof Array) {
if (!this[a].eql(arr[a])) return false;
} else if (this[a] != arr[a]) {
return false;
}
}
}
return true;
};
// Runs block on every item in the array 
// Returns true if the function returns true for every item

Array.prototype.every = function(block) {
var a = this.length;
while (--a -(-1)) {
if (!block(this[a])) return false;
}
return true;
};
// Sets the selected elements of Array (which may be the entire array)
to obj
// A start of undefined is equivalent to zero. 
// A length of undefined is equivalent to Array.length.

Array.prototype.fill = function(obj, start, len) {
if (!start) start = 0;
if (len == undefined) len = this.length;
len = start + len;
if (len > this.length) len = this.length;
while (--len - (-1) > start) {
this[len] = obj;
}
};
// Runs a function on every item in the array
// Returns an array of all items for which the function returns true.
Array.prototype.filter = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (block(this[a])) r.push(this[a]);
}
return r;
};
// Returns a new array that is a one-dimensional flattening of this

RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Mike Mountain
Doh, scrolled right past it, nice work.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of janosch
> Sent: 26 July 2006 11:04
> To: Flashcoders mailing list
> Subject: Re: [Flashcoders] Array Empowerment
> 
> uniq is the appropriate function
> 
> Janosch
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread janosch

uniq is the appropriate function

Janosch



Mike Mountain schrieb:


Yup good to see, an optimised "remove duplicate items" would be good, or
have I missed it?

 


-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf 
Of Hans Wichman

Sent: 26 July 2006 10:41
To: Flashcoders mailing list
Subject: Re: [Flashcoders] Array Empowerment

Hi Steven,
awesome, very welcome additions.
Would addIfNotPresent (in want of a better name), 
getRandomItem(with the option of deleting that randomItem), 
randomizeOrder , make any sense to add as well? Or am I 
missing something (with respect to the code that is).


greetz
Hans


   


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


 



___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-26 Thread Mike Mountain
Yup good to see, an optimised "remove duplicate items" would be good, or
have I missed it?

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf 
> Of Hans Wichman
> Sent: 26 July 2006 10:41
> To: Flashcoders mailing list
> Subject: Re: [Flashcoders] Array Empowerment
> 
> Hi Steven,
> awesome, very welcome additions.
> Would addIfNotPresent (in want of a better name), 
> getRandomItem(with the option of deleting that randomItem), 
> randomizeOrder , make any sense to add as well? Or am I 
> missing something (with respect to the code that is).
> 
> greetz
> Hans
> 
>
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-26 Thread Hans Wichman

Hi Steven,
awesome, very welcome additions.
Would addIfNotPresent (in want of a better name), getRandomItem(with the
option of deleting that randomItem), randomizeOrder , make any sense to add
as well? Or am I missing something (with respect to the code that is).

greetz
Hans


On 7/26/06, Mike <[EMAIL PROTECTED]> wrote:


Question totally unrelated to implementation and optimization:

Why do the function names have underscores when "camel-humped" names are
the customary syntax in ActionScript (and Java, and Javascript...)?

Some of the names could be clearer:
- "nitems" looks like "number of items" (i.e., "length"); why not
"numSetItems" or "countSetItem"?
- "rindex" is a bit confusing; why not "lastIndexOf" (as in the String
object)? (Also "index" could be "indexOf", to better agree with the
String interface.)
- "some" -- maybe "forSome", or "exists"? (Also, "every" makes more
sense to me as "forAll".)
- "uniq" -- do those two characters make much difference?
- "eql" -- "equals" is far more standard
- "include" is pretty close to a reserved word -- why not "hasItem"?
- the "delete" functions don't so much "delete" (i.e., totally destroy)
as "remove" or "strip".

Cool stuff, though!
--
T. Michael Keesey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ryanm
Sent: Tuesday, July 25, 2006 7:31 PM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] Array Empowerment

> Here is the next iteration - new and improved.   Again, all
> comments and optimizations, including conversations about
> optimizations, are most welcome!
>
   Those are great additions. You need a duplicate_deep and a
replicate_deep, though. Right now, any obejcts stored in the array will
be
references in the new array. A _deep method would make copies of those
too,
recursively caling Array.duplicate, or Object.duplicate. ;-)

ryanm

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-25 Thread Mike
Question totally unrelated to implementation and optimization:

Why do the function names have underscores when "camel-humped" names are
the customary syntax in ActionScript (and Java, and Javascript...)?

Some of the names could be clearer:
- "nitems" looks like "number of items" (i.e., "length"); why not
"numSetItems" or "countSetItem"?
- "rindex" is a bit confusing; why not "lastIndexOf" (as in the String
object)? (Also "index" could be "indexOf", to better agree with the
String interface.)
- "some" -- maybe "forSome", or "exists"? (Also, "every" makes more
sense to me as "forAll".)
- "uniq" -- do those two characters make much difference?
- "eql" -- "equals" is far more standard
- "include" is pretty close to a reserved word -- why not "hasItem"?
- the "delete" functions don't so much "delete" (i.e., totally destroy)
as "remove" or "strip".

Cool stuff, though!
--
T. Michael Keesey

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of ryanm
Sent: Tuesday, July 25, 2006 7:31 PM
To: Flashcoders mailing list
Subject: Re: [Flashcoders] Array Empowerment

> Here is the next iteration - new and improved.   Again, all
> comments and optimizations, including conversations about
> optimizations, are most welcome!
>
Those are great additions. You need a duplicate_deep and a 
replicate_deep, though. Right now, any obejcts stored in the array will
be 
references in the new array. A _deep method would make copies of those
too, 
recursively caling Array.duplicate, or Object.duplicate. ;-)

ryanm 

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com

___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


Re: [Flashcoders] Array Empowerment

2006-07-25 Thread ryanm

Here is the next iteration - new and improved.   Again, all
comments and optimizations, including conversations about
optimizations, are most welcome!

   Those are great additions. You need a duplicate_deep and a 
replicate_deep, though. Right now, any obejcts stored in the array will be 
references in the new array. A _deep method would make copies of those too, 
recursively caling Array.duplicate, or Object.duplicate. ;-)


ryanm 


___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


RE: [Flashcoders] Array Empowerment

2006-07-25 Thread Steven Sacks | BLITZ
Here is the next iteration - new and improved.   Again, all comments and
optimizations, including conversations about optimizations, are most
welcome!

// Array Empowerment
// Removes all elements from Array
Array.prototype.clear = function() {
this.length = 0;
};
// Invoking block once for every element, passing each element as a
parameter to block
// The result of block is used as the given element in the array
Array.prototype.collect = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
this[a] = block(this[a]);
}
};
// Removes all null and undefined elements from Array
Array.prototype.compact = function() {
var i = -1;
var n = this.length;
var r = [];
for (var a = 0; a < n; a++) {
if (this[a] != null && this[a] != undefined) {
r.push(this[a]);
}
}
};
// Deletes items from the Array that are equal to obj
Array.prototype.delete_all = function(obj) {
var n = this.length;
var r = [];
if (!(obj instanceof Array)) {
for (a = 0; a < n; a++) {
if (this[a] == obj) r.push(this[a]);
}
} else {
for (a = 0; a < n; a++) {
if (!this[a].eql(obj)) r.push(this[a]);
}   
}
this.replicate(r);
};
// Deletes the element at the specified index, returning that element,
or undefined if the index is out of range
Array.prototype.delete_at = function(i) {
if (i < this.length && i > -1) return this.splice(i, 1)[0];
return undefined;
};
// Deletes every element of Array for which block evaluates to true
Array.prototype.delete_if = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (!block(this[a])) {
r.push(this[a]);
}
}
this.replicate(r);
};
Array.prototype.duplicate = function() {
var r = [];
var a = this.length;
while (--a -(-1)) {
r[a] = this[a];
}
return r;
};
Array.prototype.replicate = function(r) {
this.length = 0;
var a = r.length;
while (--a -(-1)) {
this[a] = r[a];
}
};
// Calls block once for each element in Array, passing that element as a
parameter
Array.prototype.each = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(this[a]);
}
};
// Same as Array.each, but passes the index of the element instead of
the element itself
Array.prototype.each_index = function(block) {
var n = this.length;
for (var a = 0; a < n; a++) {
block(a);
}
};
// An array is equal to another array if the lengths are equal and each
corresponding element is equal
Array.prototype.eql = function(arr) {
if (arr.length != this.length || !(arr instanceof Array)) {
return false;
} else {
var a = this.length;
while (--a -(-1)) {
if (this[a] instanceof Array) {
if (!this[a].eql(arr[a])) return false;
} else if (this[a] != arr[a]) {
return false;
}
}
}
return true;
};
// Runs block on every item in the array 
// Returns true if the function returns true for every item
Array.prototype.every = function(block) {
var a = this.length;
while (--a -(-1)) {
if (!block(this[a])) return false;
}
return true;
};
// Sets the selected elements of Array (which may be the entire array)
to obj
// A start of undefined is equivalent to zero. 
// A length of undefined is equivalent to Array.length.
Array.prototype.fill = function(obj, start, len) {
if (!start) start = 0;
if (len == undefined) len = this.length;
len = start + len;
if (len > this.length) len = this.length;   
while (--len - (-1) > start) {
this[len] = obj;
}
};
// Runs a function on every item in the array
// Returns an array of all items for which the function returns true.
Array.prototype.filter = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (block(this[a])) r.push(this[a]);
}
return r;
};
// Returns a new array that is a one-dimensional flattening of this
Array (recursively)
// That is, for every element that is an array, extract its elements
into the new array
Array.prototype.flatten = function(r) {
if (!r) r = [];
var l = this.length;
for (var a = 0; a < l; a++) {
if (!(this[a] instanceof Array)) {
r.push(this[a]);
} e

RE: [Flashcoders] Array Empowerment

2006-07-25 Thread Steven Sacks | BLITZ
Thank you for your comments.  Writing these methods is like creating and
solving little puzzles.  Much fun!


> > // Remove all elements from Array
> > Array.prototype.clear = function() {
> > this.length = 0;
> > };
> 
> This function scares me to death.

According to the official Flash documentation

"Note: If you assign a value to the length property that is shorter than
the existing length, the array will be truncated."  


> Which is faster, iterating over an array of size N once and checking
> for elements that are either null or undefined in a single pass, or
> iterating over an array of size N checking for nulls and then
> iterating again over an array of size N-x and checking for the
> undefineds?

You're right. I've updated my script.


> You do this sort of thing in several of your functions and I think you
> _might_ be able to squeeze a bit of theoretical speed out of things by
> 
> if obj is an array
>loop checking for array equality
> else
>loop checking for value equality
> 
> In stead of
> 
> loop over the entire array
>   check value equality
>   if obj is an array
> check array equality

Good catch.  I've added an or to the first if in the eql method to
verify the argument passed is an array and have changed the other
methods so instanceof checks happen as infrequently as possible.  I've
also modified all the places that I run these if statements to minimize
instanceof checks.


> Also, what's the performance hit for splice()? I know it's bad in some
> languages. Would it be potentially faster to build a new array in
> stead of re-splicing the old one? I guess it depends on the length of
> the array as compared to the number of elements being removed. What is
> the threshold where one becomes preferrable to the other?

Splice is slow.  Creating a new array is preferable but reassigning
another array to 'this' doesn't work inside a prototype because an
instance can't delete or replace itself.  But, clearing the array and
reiterating is a better overall strategy than splicing.  I wrote a pair
of methods to help.

Director has a method 'duplicate' which is missing from Flash.  I have
added that and its sister method, 'replicate' to my extension.
duplicate makes a copy of 'this' in a new array and returns it,
replicate turns 'this' into a copy of another array.


> > filter
> I love this one. I use it absolutely all the time in other languages.

RecordSet has it, but Arrays do not.  About time, too.
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com


re: [Flashcoders] Array Empowerment

2006-07-25 Thread Ammon Lauritzen

A few thoughts on optimization. Just thoughts.

Steven Sacks | BLITZ wrote:

// Remove all elements from Array
Array.prototype.clear = function() {
this.length = 0;
};


This function scares me to death. I understand that the garbage
collection in any decent VM should take care of this... but wow, it
feels like some dangerous voodoo. :)


// Removes all null and undefined elements from Array
Array.prototype.compact = function() {
this.delete_all(null);
this.delete_all(undefined);
};


Which is faster, iterating over an array of size N once and checking
for elements that are either null or undefined in a single pass, or
iterating over an array of size N checking for nulls and then
iterating again over an array of size N-x and checking for the
undefineds?


// Deletes items from the Array that are equal to obj
Array.prototype.delete_all = function(obj) {
var i = -1;
var a = this.length;
while (--a -(-1)) {
if (this[a] == obj) {
i = a;
break;
} else if (this[a] instanceof Array && obj instanceof
Array) {
if (this[a].eql(obj)) i = a;
break;
}
}
if (i > -1) {
this.splice(i, 1);
this.delete_all(obj);
}
};


You do this sort of thing in several of your functions and I think you
_might_ be able to squeeze a bit of theoretical speed out of things by

if obj is an array
  loop checking for array equality
else
  loop checking for value equality

In stead of

loop over the entire array
 check value equality
 if obj is an array
   check array equality

It's not much, but over a few thousand comparrisions it might make a difference?

Also, what's the performance hit for splice()? I know it's bad in some
languages. Would it be potentially faster to build a new array in
stead of re-splicing the old one? I guess it depends on the length of
the array as compared to the number of elements being removed. What is
the threshold where one becomes preferrable to the other?


// Runs a function on every item in the array
// Returns an array of all items for which the function returns true.
Array.prototype.filter = function(block) {
var r = [];
var n = this.length;
for (var a = 0; a < n; a++) {
if (block(this[a])) r.push(this[a]);
}
return r;
};


I love this one. I use it absolutely all the time in other languages.

Ammon
___
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders

Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com