No need to change the name IMO. We didn't get AS3.1 when we got Vectors or native JSON support.
brought to you by the letters A, V, and I and the number 47 On Tue, Feb 5, 2013 at 1:13 PM, Avi Kessner <akess...@gmail.com> wrote: > If you have a bunch of if statements, then that means you are doing > something significant and need multiple functions. And it would be good for > those using the code to know what it's doing. If however it's just casting > the var and sending it off, then you don't really need a bunch of if > statements. > > Personally, I have been confused by overloaded functions more than once, > (reading the wrong api documentation, or trying to pass in the wrong var > types) and I don't think I've ever thought "Wow! I'm so glad they > overloaded this function!" > > It seems to me that it exists in other languages for historical reasons > and not for theoretical reasons like generics. > > brought to you by the letters A, V, and I > and the number 47 > > > On Mon, Feb 4, 2013 at 8:47 PM, Nick Collins <ndcoll...@gmail.com> wrote: > >> This would also mean having to put in a bunch of if...else statements or a >> switch statement to check the type of var and call the appropriate method. >> To me that is code smell much bigger than method overloading :) >> >> >> On Sun, Feb 3, 2013 at 7:48 AM, Nicholas Kwiatkowski <nicho...@spoon.as >> >wrote: >> >> > One quick example -- in my ArduinoANE (an AIR ANE that allows you to >> send >> > data over a serial port), I have to have at least 5 functions that do >> the >> > same thing -- they just accept different variable types. >> > >> > Ultimately, I'd like my API to be >> > >> > serial.send(var); >> > >> > but I have to have : >> > >> > serial.sendAsInt(int); >> > serial.sendAsObject(object); >> > serial.sendAsArray(array); >> > serial.sendAsString(string); >> > serial.sendAsByteArray(ba); >> > serial.sendAsByte(int); >> > serial.sendAsFloat(float); >> > .... >> > .... >> > >> > This means that the end-developer needs to know all these different >> > function names instead of one. Sure, a good IDE helps with that, but it >> > seems unnecessary. It also prevents me from allowing better code-reuse, >> > etc. >> > >> > -Nick >> > >> > >> > On Sun, Feb 3, 2013 at 7:13 AM, Avi Kessner <akess...@gmail.com> wrote: >> > >> > > I can not for the life of me understand the desire for overloading >> > > functions. If it has different behavior give it a different name. >> > > >> > > brought to you by the letters A, V, and I >> > > and the number 47 >> > > >> > > >> > > On Sun, Feb 3, 2013 at 1:53 PM, Roland Zwaga <rol...@stackandheap.com >> > > >wrote: >> > > >> > > > +100.000 for generics (although I fully understand that this is >> > probably >> > > > one of the most difficult features to implement) >> > > > >> > > > +1 for lamba expressions >> > > > >> > > > On 3 February 2013 12:48, christofer.d...@c-ware.de < >> > > > christofer.d...@c-ware.de> wrote: >> > > > >> > > > > +1 for method overloading from me too >> > > > > >> > > > > And: >> > > > > >> > > > > +1 for private/protected constructors :-) >> > > > > >> > > > > >> > > > > >> > > > > -----Ursprüngliche Nachricht----- >> > > > > Von: Frédéric THOMAS [mailto:webdoubl...@hotmail.com] >> > > > > Gesendet: Sonntag, 3. Februar 2013 05:16 >> > > > > An: dev@flex.apache.org >> > > > > Betreff: Re: Language features >> > > > > >> > > > > Nick, +1 or even 10 >> > > > > >> > > > > -Fred >> > > > > >> > > > > -----Message d'origine----- >> > > > > From: Nicholas Kwiatkowski >> > > > > Sent: Saturday, February 02, 2013 6:58 PM >> > > > > To: dev@flex.apache.org >> > > > > Subject: Re: Language features >> > > > > >> > > > > I'd be fairly excited to see method overloading. It's one of the >> > > things I >> > > > > miss from Java... >> > > > > >> > > > > -Nick >> > > > > >> > > > > On Sat, Feb 2, 2013 at 12:17 PM, Avi Kessner <akess...@gmail.com> >> > > wrote: >> > > > > >> > > > > > If it was up to me, I would vote against method overloading. I >> > think >> > > > > > that's a code smell personally. >> > > > > > >> > > > > > brought to you by the letters A, V, and I and the number 47 >> > > > > > >> > > > > > >> > > > > > On Sat, Feb 2, 2013 at 7:05 PM, Frédéric THOMAS < >> > > > webdoubl...@hotmail.com >> > > > > > >wrote: >> > > > > > >> > > > > > > Hi Gordon, >> > > > > > > >> > > > > > > >> > > > > > > Adding abstract classes and private constructors to Falcon >> > should >> > > be >> > > > > > easy >> > > > > > >> >> > > > > > > >> > > > > > > That's a good news, at this point protected constructor would >> be >> > > > > > > welcomed >> > > > > > > as well as private constructors are commonly used in classes >> that >> > > > > > > contain >> > > > > > > static members only. >> > > > > > > >> > > > > > > And I voting +1 for the rest :-) you gonna make happy a lot of >> > > people >> > > > > > > who >> > > > > > > wait for a long time for these features. >> > > > > > > >> > > > > > > -Fred >> > > > > > > >> > > > > > > -----Message d'origine----- From: Gordon Smith >> > > > > > > Sent: Friday, February 01, 2013 7:38 PM >> > > > > > > To: dev@flex.apache.org >> > > > > > > Subject: RE: Language features >> > > > > > > >> > > > > > > >> > > > > > > Adding abstract classes and private constructors to Falcon >> should >> > > be >> > > > > > easy. >> > > > > > > Adding generics and method overloading would be considerably >> > harder >> > > > but >> > > > > > > probably doable after a lot of design. Two other features >> worth >> > > > > > considering >> > > > > > > are strong function types (i.e., a type like (int, int):String >> > for >> > > a >> > > > > > > function that takes two ints and returns a String) and >> > > strongly-typed >> > > > > > fixed >> > > > > > > arrays (i.e., int[]). >> > > > > > > >> > > > > > > I'm going to continue to focus on MXML. Until it is finished, >> we >> > > > can't >> > > > > > > move from the old compiler to the new one. I don't recommend >> > making >> > > > any >> > > > > > > modifications to the old compiler. >> > > > > > > >> > > > > > > - Gordon >> > > > > > > >> > > > > > > -----Original Message----- >> > > > > > > From: Frédéric THOMAS [mailto:webdoublefx@hotmail.**com< >> > > > > > webdoubl...@hotmail.com> >> > > > > > > ] >> > > > > > > Sent: Friday, February 01, 2013 3:07 AM >> > > > > > > To: dev@flex.apache.org >> > > > > > > Subject: Re: Language features >> > > > > > > >> > > > > > > +1 Nick >> > > > > > > >> > > > > > > May be possible, I don't know, time ago, I looked at adding >> the >> > > > > > > possibility to have the constructor accepting other NS than >> > public >> > > to >> > > > > > > simulate abstract classes and seen 2 places where it was >> checked >> > > but >> > > > > > didn't >> > > > > > > dare to change it besause I didn't know the impacts, I hope >> > someone >> > > > > > better >> > > > > > > than me here can take care of it, compiler geeks, are you >> here ? >> > > > > > > >> > > > > > > -Fred >> > > > > > > >> > > > > > > -----Message d'origine----- >> > > > > > > From: Nick Collins >> > > > > > > Sent: Friday, February 01, 2013 11:24 AM >> > > > > > > To: dev@flex.apache.org >> > > > > > > Subject: Language features >> > > > > > > >> > > > > > > With the cancellation of AVM next, should we perhaps look at >> > adding >> > > > > some >> > > > > > > additional language features to our compiler? >> > > > > > > >> > > > > > > As I think about some of the features I would like to see, >> such >> > as >> > > > > > > abstract classes, generics, method overloading, etc. it seems >> to >> > me >> > > > > that >> > > > > > at >> > > > > > > least some of them could be implemented into our compiler? >> > > > > > > >> > > > > > > Nick >> > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > >> > > > >> > > > >> > > > -- >> > > > regards, >> > > > Roland >> > > > >> > > > -- >> > > > Roland Zwaga >> > > > Senior Consultant | Stack & Heap BVBA >> > > > >> > > > +32 (0)486 16 12 62 | rol...@stackandheap.com | >> > > > http://www.stackandheap.com >> > > > >> > > > http://zwaga.blogspot.com >> > > > http://www.springactionscript.org >> > > > http://www.as3commons.org >> > > > >> > > >> > >> > >
