|
SoCoder -> Blogs Home -> Blogs |
|
|
|
|
JL235
|
Transparent Arrays |
|
Last night I had a brainwave on a new language feature for Quby. I suspect this exists in other languages already, however it doesn't in many mainstream ones. The problem is that you often want to hold a collection of values and then perform an operation on each element. Like ... So why not make the fact that it is an array transparent? Like ... When 'update' and 'draw' are called, they are automatically called on each element in the array for you. Just like JQuery! Some semantics tho, I think I'd be happier if I made the syntax for creating a transparent array separate to a standard one. Such as... Obviously the first is the cleanest, but also requires language changes (do I really want to bake this in?). I'd also have to work out how to handle code such as ... ... where it should be applying the above if to _each_ element in objs. If it could be cleanly done, this could be very powerful! |
|
|
|
|
Comments |
|
| Friday, 04 February 2011, 18:37 | |
|
CodersRule |
I feel like I've seen this before. Hm. Also, do you need to specifically denote which arrays are transparent? I would think it's unnecessary. Please correct me if I'm wrong. 
|
| Friday, 04 February 2011, 19:24 | |
Evil Roy Ferguso
|
I like how concise this is, but I sort of feel like it would add undue complexity to the language, especially since you don't really "get" anything new. Also, what if somebody has an array of balloons and they call "arr.pop()"? Would every balloon pop, or would the last element of the array get removed? I can imagine it being a little confusing, even if the behavior is well-defined. Maybe instead of having a separate kind of array, have some syntactical sugar for creating a block that just calls a method on an object, which you could then pass in to each? Possibly something like: "=> something" would basically just construct this block: I feel this would give some of the benefits of transparent arrays without introducing (as big of) a new concept. The full example seems nifty but I think it could get pretty confusing. It's like, what if you want to apply something to every element of objs in the second else, instead of only to the "matched" elements, or vice versa? The challenge would making those semantics obvious and cleanly expressible. If you figure it out, though, that would be very interesting. As far as actual transparent arrays are concerned, though, I like the .toTransparent() method syntax better than angle brackets or the "new" option, but this is mostly because angle brackets softly whisper "these are generic type parameters" to me. |
| Saturday, 05 February 2011, 02:51 | |
Jayenkai
|
Jay's answer : No, because that's not how I code! Just look at my arrays. One array, whole buttloads of different pieces of data. What you're doing is Types/Objects. Leave the array be, because I'm not the only one who codes like this. If I wanted types/objects, I'd happily use those.
|
| Saturday, 05 February 2011, 13:37 | |
JL235
|
I think your actually in the minority there Jay. Most programmers keep arrays to a single type, or at most also allow null elements. Very few people use arrays your way.
|
| Saturday, 05 February 2011, 16:20 | |
|
Jayenkai
|
Yeah, you're probably right. Build for the future.
|
| Monday, 07 February 2011, 21:16 | |
|
mindstorm8191 |
Blitz already allows something very similar with its Types, using a For-Each loop. But something using arrays might appear alot cleaner. To approach the problem you were mentioning, functions that return a value should instead return arrays (or lists). So before you could do your if-then statement in your code, you could use Sum or Average on it to get to a single value.
|
| Monday, 07 February 2011, 23:13 | |
|
JL235
|
mindstorm  To approach the problem you were mentioning, functions that return a value should instead return arrays (or lists). So before you could do your if-then statement in your code, you could use Sum or Average on it to get to a single value. That's the approach I was thinking. There are some corner cases however; but storing some info internally can work around this. One of the big issues is that a naive approach could run a for loop each time you interact with the array; this could end up costing a lot of overhead. A proper solution would move the entire if statement into a for-loop and run it on each element, but that would require lots of tracing to work out if it's safe to do so or not. |
|
|
| |||
|
| ||||