Is there any open source collection framework, written in ActionScript that would emulate HashMap, HashSet, LinkedHashMap and LinkedHashSet Java class implementations.
AS3Commons Collections include (besides others):
ArrayList, SortedList
Set, LinkedSet, SortedSet
Map, LinkedMap, SortedMap
LinkedList, Treap
The project is currently the first address for a serious AS collections framework: It consists of a high level framework architecture, the most comprehensive set of different collections and the fastest collection implementations. Additionally, most of the collections come in a bindable version to be connected to user interfaces.
AS3Commons Collections | .../as3commons-collections/
Collections Performance Tests | .../collections-framework-performance-comparision/
AS3Commons Organization | http://as3commons.org/
And, yes, I am the author :-)
Eric Feminella's HashMap is very nice.
Check the Lite Collections for ActionScript 3. We are currently talking with the author about making this an AS3Commons project.
Have a look at AS3 Data Structures (AS3Ds) by polygonal
Related
I want to use immutable persistent collections, like the ones Clojure uses, in Kotlin. Which libraries can I use (both in the JVM and in Javascript)? How well they integrate with Kotlin?
As answered in this SO-Question, there are several Java libraries you can easily use in Kotlin:
Guava (https://github.com/google/guava)
Dexx (https://github.com/andrewoma/dexx)
Eclipse Collections (formerly GS-Collections, https://www.eclipse.org/collections/)
PCollections (http://pcollections.org/)
The most interesting thing: Kotlin has its own solution, which can be found here: https://github.com/Kotlin/kotlinx.collections.immutable (based on PCollections).
I started Meteor a few months ago.
I would like to know if using cursor.observeChanges for buisness objects is a good idea
I want to separate operations and views so I can uses the same operations in many views/events, and I want to know if it is a good idea.
Someone told me, we should not separate operations on mongo from view.
So my question is : Is it a good idea to to Buisness Objects with Meteor ?
Tanks for reading me.
cursor.observeChanges is essentially what you get behind the scenes when you do normal find() queries and bind to template helpers due to its context being reactive.
In the meteor world, the traditional model/view/controller paradigm is shifted towards a reactive data-on-the-wire concept including features like latency compensation.
What you refer to as a business object is basically a representation of your business data which is strongly typed, has a type of its own, atomic, and has only one task of representing.
You can achieve that kind of separation of concerns in any language/framework, including meteor. That only depends on how you lay out, structure and abstract your code.
What Meteor brings into the equation is the toolset to build up an interface to your data with modern ux features that are otherwise very hard/expensive to get.
The only concern over business-class applications could be the fact that Meteor currently employs MongoDB by default. MongoDB has its own discussions around business applications whether they need transaction support, ad-hoc aggregation, foreign key relationships etc. But that is another topic.
The new read-only interfaces in .NET 4.5 such as IReadOnlyCollection<T> and IReadOnlyDictionary<TKey,TValue> are very useful, especially since they have been implemented on common BCL types such as Collection<T>, List<T> and Dictionary<TKey,TValue>.
However, HashSet<T> and SortedSet<T> haven't been upgraded to implement IReadOnlyCollection<T>, and I can't see the logic behind this decision since those classes match the interface without any modification or breaking change. Was it just overlooked by the BCL team, or is there something I'm missing here?
(This is especially annoying since there are no built-in ways to wrap a set inside a IReadOnlyCollection<T>. Indeed, ReadOnlyCollection<T> wraps IList<T> and not ICollection<T>. I know writing my own wrapper is trivial.)
Update 2015: Fixed in .NET 4.6
Read-only interfaces are implemented on collection types HashSet, LinkedList, Queue, SortedDictionary, SortedList, SortedSet, and Stack. [944715]
https://dotnet2015.blob.core.windows.net/changes/dotnet46-changes.txt
The most likely reason the IReadOnlyXxx interfaces where added in 4.5 was because they were required to make .NET collections usable in WinRT projects (Store and Phone apps). Necessary to properly map the collection to WinRT's IVectorView<> and IMapView<> interfaces. This is done automagically by the language projection built into the CLR. With the clincher that WinRT doesn't have the equivalent of an ISet<> interface so there just wasn't any need to change HashSet<>.
Update: the asymmetry was resolved in .NET 4.5.1, no doubt thanks to plenty of customer feedback :), HashSet<> now also implements IReadOnlyCollection<>
I generally use IoC pattern in my projects which are most of the time ASP.net based. Are there any guidelines on how to structure the projects in a general 3 layered project UI+BL+Data Access. I want to know more about how the folders should be created, where should constants be kept at within each layer (I keep all the strings such as query string parameters, stored procedure parameter etc in file named Constants which is singleton). How should I create classes that interact with Data Access layer from Business Layer etc. and all such code structure questions.
Is there any guidance or a book on this?
Microsoft has a plethora of information on this. I've used Microsoft .NET: Architecting Applications for the Enterprise as my bible for software architecture
http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-Pro-Developer/dp/073562609X
Check out this MSDN guide as well
http://msdn.microsoft.com/en-us/library/ff647095.aspx
Also, take a look at some application frameworks like Sharp Architecture for examples
http://sharparchitecture.net/
A lot of NHibernate tutorials demonstrate software design principles that can be applied to any solution
http://nhforge.org/blogs/nhibernate/archive/2010/04/25/first-three-nhibernate-quickstart-tutorials-available.aspx
#robbymurphy has a great answer. I would only add that I keep most constants and interfaces in a separate project/assembly altogether. I call this my "core" assembly and and define interfaces that allow me to pass data from the top of the stack to the bottom without tightly coupling them.
It is not so much where they are used, but for what purose. I once attended a seminar class where the instructor pounded "high cohesion, low coupling" into our heads, over and over.
Keep those things that, in the real world, belong together, together, but, reduce dependencies between object whenever possible.
This is a cohesion question as well as a coupling issue: if the constants are truly internal to a class, make them private static members (i.e. and internal state enum) . If they are truly internal to a project, create a class for them, and make them internal (a database specific constant in your data layer). Otherwise, put them in a public class in their own project.
I'm working on a fairly large project at the moment and am currently in the planning stages. I've done a lot of reading into the various patterns suggested for development, somthing that has split the team at the moment is when using Entity Framework should the classes be passed through the applciation layers so that a view accepts an Entity Framework class or should these classes be mapped to BLL Classes and if so at which point (Controller or Library) should this be done?
I'm interested in hearing some positives and negitives for each solutions.
This is one of those great "it depends" questions ....
For me it's a matter of pragmatism. I use the raw entity classes where ever I can for expediency. I start using DTOs when either the object graph in question starts becoming too cumbersome or the object in question has sensitive data I don't want sent over the wire.
This is again one of those questions that doesn't really have a right or wrong answer, its personal taste really. Personally I would opt for using DTO's or interfaces when passing data to the Views. I don't tend to pass around entity objects to different layers of my application they are strictly confined to the DAL, or if I do need to pass it up a layer I would almost always use an interface never the concrete type.