Experimental 1.47a update now available! [MONKEY NEWS]
Monkey Forums/Monkey Programming/Experimental 1.47a update now available! [MONKEY NEWS]
| ||
| Hi, Okay, I've just uploaded an experimental V47a update to the product updates section. No idea why I called it 1.47a in the topic title though... The major change is to the generics system, which has been largely rewritten and is now a whole lot more flexible - at the cost of possibly producing slightly larger output code. If you don't know much about writing generic code, this lot wont really apply to you so don't panic if it all sounds a bit heavy! In theory, it should be possible to continue using Monkey just the way you have been. Anyway, you can now use generic type params in any way you want, eg: you can use New T, return an array of T etc. Also, type params can now be of any type including Bool, Int, Float, String and Array. Finally, you can now downcast to a generic class, and use a generic class as a 'class scope'. Some examples: Class C<T> Global G:T Field F:T=10 End Function Main() C<Int>.G=1 C<Float>.G=2.0 C<Int[]>.G=[1,2,3] Print C<Int>.G Print C<Float>.G Print C<Int[]>.G.Length Local o:Object=New C<Int> Local c:=C<Int>( o ) Print c.F End For the most part, it should all be pretty much backward compatible, but I suspect there will be a few curly cases where things don't quite work the way they should/did. For example, the recent addition of the 'sentinal' object to the list class no longer works with the new system so had to be tweaked, and I suspect there may be similar issues with 3rd party classes. Feel free to post any problems you have here. I also changed the built in IntList, FloatList, IntStack, FloatStack etc classes to use List<Int>, Stack<Int> etc. Previously, these classes used 'box' objects, so this change may cause minor problems if you were using the boxes directly for some reason. But such issues should be easy to fix, and the new versions should be much more efficient. There were more modifications I could have made, but thought that was enough for starters! Modules: mojo.graphics - Changed XNA PlayMusic to use MediaPlayer. Monk (0.35) Applied MaxIDE tab width & SaveText fixes and recompiled with new MaxGUI. Trans (1.22) XNA target changed to treat WAV files as sounds, MP3 and WMA files as music. Generics system majorly overhauled, now uses 'reification' instead of 'type erasure'. Oops...also forgot to include doc updates...later... |
| ||
| Finally, you can now downcast to a generic class, and use a generic class as a 'class scope'. I love you. Now add them to interfaces. ;) |
| ||
| Me too. This is awesome! |
| ||
| The following code compiles fine in v46, but in v47a it throws this error: Compile Error Identifier 'E' not found. Strict Function Main:Int() Local al:ArrayList<Sprite> = New ArrayList<Sprite> al.Get(0) Return 0 End Class Sprite Field x:Float, y:Float End Class ArrayList<E> Field elements:Object[] Method Get:E(index:Int) Return E(elements[index]) ' <----- Identifier E not found!?!?! End End BTW Mark if you want a really good piece of code to test Generics with load up the Diddy GUI example ;) |
| ||
| Also, type params can now be of any type including Bool, Int, Float, String and Array. That's something I was wondering when using Monkey for the first time. Glad you add it. Thanks |
| ||
| This is awesome. I wholeheartedly approve... |
| ||
| wooohoo! good steeuff for doing this improvement, gonna make things a lot more flexible... |
| ||
| Does it make me look lame if I say I have no clue what you're all talking about? :D |
| ||
| i yet have so much to learn dont know half of what you guys are talking about. type params? dont know. plus more other stuff. having many headaches causes me to be a slow learner but thats what i got to live with. |
| ||
| Looks great! |
| ||
| yeah! I'll add to the choir... this is awesome. the limitations before had me kludging in some things that I can now remedy. |
| ||
| Hi, > Compile Error > Identifier 'E' not found. Ok, fixed in the just-uploaded V47b. > BTW Mark if you want a really good piece of code to test Generics with load up the Diddy GUI example ;) Had a quick go at this but didn't get far. There are bits in the collections module that need to be fixed - in particular, stuff like this seems to be common: Method Get:E( index) Return data[index] 'where data is an Object[] - needs downcast at least! End The fix is to either declare data as a T[], or to return E(data[index]) instead, as per above bug report! |
| ||
| Method Get:E( index) Return data[index] 'where data is an Object[] - needs downcast at least! End Where? I can't see that anywhere. Edit: I've found two instances in ArrayListEnumerator, so I wouldn't exactly call it common. Regardless, it should have failed compilation anyway (which it does now). The fix is to either declare data as a T[] Pre-v47 you couldn't instantiate an array of a generic, so there's no way of dynamically creating it. or to return E(data[index]) instead It does. |
| ||
Forgive my ignorance, but what is the significance of this bit?Local o:Object=New C<Int> Local c:=C<Int>( o ) Print c.F isn't is possible to o.F for the same result? Why cast C<Int>? Oh, and one more.... C<Int[]>.G=[1,2,3] Once this is done, what is the output of Print C<int[]>.F? An error? |
| ||
| Ok, fixed in the just-uploaded V47b. Ta... The only place I had to fix was the NextObject and PreviousObject methods in ArrayListEnumerator. Had a quick go at this but didn't get far. Well when it does work, I use this to test new Monkey versions as it covers a lot of functionality. |
| ||
| @AdamRedwoods: isn't is possible to o.F for the same result? Why cast C<Int>? Because o is declared as an Object, the compiler doesn't know what F is. You need to cast o to a C<Int> first. @AdamRedwoods: Once this is done, what is the output of Print C<int[]>.F? An error? F is a field, not a global. Accessing C<Int[]>.F should give a compile error since a non-static field cannot be referenced in the scope of a class. ----- Mark, I know we have the implicit declaration operator :=, but would it be possible to get one the other way around for generics? Example: Local a:Foo<Int> = New Foo<> This would infer the <Int> from the variable type and wouldn't need to be put into the constructor. I ask this because it was added to Java 7 (the "diamond operator"). |
| ||
| Thank you for your response. F is a field, not a global. Ah, so it is... but what if it was global and assigned a value of 10? Global F:T = 10 then C<int[]>.G = [1,2,3] Print C<int[]>.F How would this change F since the type is now an int[]? |
| ||
| How would this change F since the type is now an int[]? Then it shouldn't compile. You can't assign a primitive to an array. |
| ||
| There are several globals, one for each type, if you know what I mean, |
| ||
| I have no idea what is going on with Monkey but from others responses it appears good for those who are able to code this way and for people like me, well, we're left with a 'What The ...?' feeling. I don't like this at all. Don't get me wrong Monkey is great and improving by the looks of things and again from peoples responses to these features but when I spend more time trying to figure out how to use the language than getting any coding done is when I say, thank you, but this isn't for me. Hopefully I can return to Monkey at some point and be able to get the Blitz feeling again; for now though I'll try to reassess my options. I don't need all this just to make a game. |
| ||
| I see times coming, where trying to read the code of a module is for me like reading quantum computer assembler. Hopefully I get in this stuff one day. |
| ||
| Hopefully I can return to Monkey at some point and be able to get the Blitz feeling again; for now though I'll try to reassess my options. As Mark said in the first post, if you aren't actively using these features then you can mostly ignore all of this. Most working programmers rarely get involved in the nitty-gritty of things like generics and once Monkey's feature set is stable most of this will be hidden behind collections frameworks and other libraries. |
| ||
| Amon, I also don't plan on using geriatrics in any of my code, in fact Monkey has been perfect for my needs since it was released, muddy's box2d module is the only addition I couldn't do without since. |
| ||
| Totally agree with Skid, I'm using Diddy, so if there is any of this voodoo stuff going off, I'll not see it and carry on with how I usually write stuff, I very much doubt I'll need any of this stuff too, but then, if I did, it would be a once in a blue moon occasion so I'm not going to sweat over it. I've totally fallen for monkey though (oh er missus), apart from odd niggles, its first class, and I really really hope BRL keep up with whats hot and whats not in terms of the platforms it will target, to me, that would make it shine for years to come! Dabz |
| ||
| Hi, > I have no idea what is going on with Monkey but from others responses it appears good for those who are able to code this way and for people like me, well, we're left with a 'What The ...?' feeling. I can relate to that - I understand the desire to know *all* of a language and not just to 'use' it and have it doing all this magical stuff behind your back. But at the same time, things change. A lot of people were thrown by the addition of OO features to BlitzMax and I remember similar discussions back in the day. And you don't *need* OO to write a game either, but it certainly does/can help. Would you go back to a non-OO language now? If so, or you're still struggling with OO, then perhaps Monkey really isn't your cup of tea. But if you appreciate OO, then I recommend sticking with generics for a bit longer too. Basically, I added generics to Monkey for the same reason I added OO top BlitzMax - it was a feature I felt added enough value to the language to be worth the extra complexity. And yes, this is definitely a very subjective call. I Basically just do what suits me really, and hope that it suits enough other people to be worthwhile! > I see times coming, where trying to read the code of a module is for me like reading quantum computer assembler. The stuff that's probably the most confusing in the above discussion is all the blah<etc> code. Basically, the trick here is just to remember that anything of the form blah<etc> is actually just a class, and can be used in the same ways as a 'normal' class. For example, List<Actor> is a class, and like any class you can (hypothetically - these wont all work!): * Create a new instance, eg: New List<Actor> * Downcast from a super class, eg: List<Actor>( obj ) * Create an array of instances, eg: New List<Actor>[100] * Access consts, globals or functions within the class, eg: List<Actor>.SomeGlobal But note there is nothing there you can't do with 'normal' classes - it's just that the code looks a bit trippier due to the extra <> stuff. Also, note that you can now put ANY valid type inside the <> (you used to only be able to put other classes inside <>), which can make things look even weirder. But still, even a List<Int[][]> is just a class, and can be newed, downcast etc - it just may not look all that sexy! I think some of the confusion here is that this release actually fixed a lot of this stuff, so you'll never have encountered code like G<Int>.y before because it didn't work! Anyway, I'll have a go at writing a tutorial on this. |
| ||
| Amon, I also don't plan on using geriatrics in any of my code Oh, lovely. Despite sort of getting 'geriatrics', and starting to see the point, I am still very much stuck in the... what? 2005's? But I always try to grasp the new ways, even though I hate "design patterns" and "factories" and... formalities... A lot of people were thrown by the addition of OO features to BlitzMax and I remember similar discussions back in the day. Guilty! And converted... still bravely holding off, though. |
| ||
| im only just beginning to understand generics so i looked up some tutorials on youtube they are in java but they do a good job of explaining generics and it not that different from monkey i think http://www.youtube.com/watch?v=J6B_qauxfuc http://www.youtube.com/watch?v=ZoJaD0Qoi0o&feature=mfu_in_order&list=UL i hope it helps |
| ||
| Hi, I don't think many people will be *writing* generic classes, or even should be, but I do think if you're gonna use List<>, Stack<> etc or 3rd party equivalents and want to make the most of them, you should be aware of how they work. |
| ||
| I appreciate the explanations which have settled my old skool brain a bit. I guess it was as you said, Mark, my feelings towards Generics were much like those when you added OO to BlitzMax; remembering that I managed to learn with a bit of persistence and trial and error. I am glad of the fact that to a certain extent, unless absolutely needed, that I can just continue as I am without using Generics. This is good because it means I can go code. I'm still not completely or even to a certain degree getting Generics but maybe it'll all fall in place if I encountered a scenario where Generics needed to be used. Trial and Error; Code Forever, as they say. :) |
| ||
| I think I would say to Amon what others have said: these are options. You don't have to use them if you don't want to. Volker says: "I see times coming, where trying to read the code of a module is for me like reading quantum computer assembler". In some ways this is a stronger point, but in truth a lot of the benefits of the more sophisticated features of Monkey are actually related to writing great modules. It is a bit like in C++: you might never use templates yourself, and you don't have to - but you would want to use the libraries they make possible. Even if the code in them makes your eyeballs melt. |
| ||
| nice update, What other updates are on the horizon? |
| ||
| What other updates are on the horizon? Still waiting for generic interfaces... :) |
   |