Skn3 ModulesMonkey Forums/User Modules/Skn3 Modules
| Very handy!
Added a simple array sort module. It allows for an extendable array sorting API.
If anyone would like to help by implementing some sort algorithms then that would pretty cool! It currently has one implementation for Cocktail/shaker sort.
| About ArraySorter<T>: It's a cool concept. I did something like this to port java timsort to monkey a month ago (Comparator<T>, specifically), but didn't use Abstracts. Maybe we can work together on a standard class for Comparators so other sorting algorithms can be made into drop-in replacements for 3rd party frameworks.
In case you are interested in seeing the differences in implementation:
| Hey Nobu,
interesting, how do you propose we would design it?
| Well, if Interfaces supported Generics in Monkey, I would've said that we could make Comparator<T> an interface, have ArraySorter<T> implement it, and then have TimSort<T> (as an example/reference sort) extend it. However, Interfaces can't be generic in Monkey, so I'm not sure which hierarchy would be the best for this sort of thing.
Comparators are simply a "component" which can be used, for example, to be supplied as an argument in a Sort method, allowing sort routines to be separated from the comparison method. I think this is probably a better way to go than a class which incorporated Compare and Sort methods together, although it complicates the system slightly -- end-developers probably don't have to worry about this much, since most frameworks I imagine would have made their own Comparators for the typical types.
Perhaps we could have a Sorter<T> class that is the base class for all the sorters. Making it and all its methods Abstract would make it somewhat comparable to an Interface, which I would've preferred for this project, but its definition may look something like this:
Class Sorter<T> Abstract Method Sort:Void(items:T, c:Comparator<T>) Abstract End Class
Both TimSort<T> and ArraySorterCocktail<T> should be able to extend that, with a little modification to ArraySorterCocktail<T> to take a Comparator and call its Compare method rather than ArraySorter<T>'s. The user would be able to specify their own Comparator (some examples available in comparator.monkey), allowing ascending sort, descending sort, collated sort, or anything else they could dream up, without them requiring direct alterations to our own sorting classes.
| The idea sounds good. Would you like to make the modifications? I could add you as a contributor to the repo.
| Update: Added AES encryption module.
| Okay, I've updated ArraySorter to include comparators, and updated the example to reflect their usage. I also made the code block closing statements a bit more verbose, but that's just my style :)
| Hey Nobu,
I added some changes ontop of yours, what do you think?
' - moved the ascending/descending flag to sort() method call so order is not hard-coded into comparator
' - added bool and string default comparators
' - added SortArray() api function for sorting basic data types
' - updated example to reflect changes
I moved the descending check back to the sort routine as its more flexible for the user to be able to change the sort direction per sort call instead of per comparator. Bit of commit back and forth on that, I guess I didn't understand the reasoning for having the sort direction in the comparator?
| adding the flag to the sorter class changes the method signature of all the subclasses, requiring them to implement ascending/descending support at the sorter level. I personally feel that the sorter should be order-agnostic, as this is a typically a function of the comparison method, and not the sort method. My recommendation is to revert the changes which moved the ordering functionality to ArraySorter back to Comparator. I'll give you my rationale for originally moving the ordering method in more detail here:
Imagine if someone wanted to implement a region-specific string-collating routine (say where alphabets are ordered differently than in english/ASCII) -- having the ordering technique baked into the generic ArraySorter class breaks this potential functionality, and semantically (imho, anyway!) isn't a clean break between sorting and comparing anymore. Another example may be to sort strings with prefixed numbers (like music tracks) based on that number's value rather than its position in the character table.
When the ordering technique is a property of the Comparator itself, then any custom implementation of a Comparator can include whatever sorting methods are applicable to that particular type. The Sorter doesn't have to care how the coder (or end-user) wishes to order their array. Some types might not even be applicable to an ascending/descending ordering, so having ordering as part of the method signature requirement in ArraySorter also means that these types would have to dummy-out that functionality.
The rest of the work looks solid to me on first glance. (disclaimer: I just woke up and only got 3hrs sleep last night!) I haven't tried the String comparator yet, but I wasn't aware that strings could be directly compared with the built-in operators -- This is a bit opaque to me, so I wonder what's going on in there. By the way, if you were wondering, I modeled the variable names in comparator.monkey after the Compare method in list.monkey, for consistency.
Oh, and a workaround to address the change in ordering at the sort level: Just adjust the ordering variable(s) for your Comparator after you've created an instance of it right before sorting. One extra line of code, but easy-peasy and infinitely flexible.
| Yeah I see what you mean. How about if we have keep the descending param in the sort method but pass it along to the comparator compare method (from the sort method). That way we get the best of both worlds. Unbroken sort for complex examples and ease of use for the user. It doesn't take much code to implement it once by the sort routine developer instead of every time for the end-user.
Check the repo now I have implemented it.
| If that's how you prefer it, that's fine. I think it's a bit ugly, but I'm viewing it from my own thought-processes, and it does work (and shouldn't affect the functionality). If this style of sorter becomes the standard, I'll add a comparable method signature to TimSort<T> to make it compatible with ArraySorter<T>.
| Yeah its not exactly pretty but it makes the actual game/app code nicer.
| Added ImageBuffer Module
| Some very nice work there Jon. Thanks for sharing.
| Added Screen Resolution Changer Module
| Added Check Online Module
| Added NativeUI Module
| Added QR Code Module