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<>
Related
Not looking for any recommendations, just an objective assessment if any JavaScript framework can be type-checked with Flow in the current state.
With Flow decreasing in popularity compared to TypeScript, framework declaration files tend to be written in TypeScript, and conversion is not trivial nor automatic. Is there still a framework that works well with Flow type inference, or for which you can write your own framework declarations on the fly? Or is Flow mostly used for framework-agnostic business logic today?
So the main one is react, given that its type defs are built directly into the flow project. The other which I haven't looked into personally is Vue, given that it's written in flowtype. But I cannot confirm how to get their type defs as I haven't used it personally.
But even if a library doesn't ship with type defs, it doesn't mean it doesn't support flow. One clear example is styled-components, it's built in flow with first class flow support but do not ship out of the box. Instead their defs are shipped via flow-typed. I'm not sure what their reasoning is, but most likely it's to remove coupling of flow version with styled-component version, and consumers can upgrade each independently.
Overall if you can't find a lib def readily, either not many people use it with flow or the consumers don't bother and just use the types as any. Since there are many projects in the world that don't use any static type checker, having partial static analysis may be good enough.
Answering my own question, I think looking into the flow-typed repo and look for a particular lib or framework will answer this. No recent update = no support, unless you have time and interest to make a PR yourself.
https://github.com/flow-typed/flow-typed
I want to use realm and I dont know whats so different
Dynamic framework version and static framework version of realm.
(which one is more popular in usage?)
Is anyone can describe a difference with 'easy' words ??
Thanks
It is described here: https://realm.io/docs/java/latest/#dynamic-realms
But the main difference is that a DynamicRealm is not type-safe and does not enforce your schema. Everything you are specified using Strings, whic means they are slower and more unsafe than the static Realm that uses the type system. So unless you are dealing with really dynamic data or migrations I would encourage you to stay with the static Realm. That way you get the full benefit of a statically typed language like Java, less bugs and faster code.
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.
I'm in the middle of creating a fairly large flex application, and over time, it's started to edge toward unmaintainability.
I'm using 3 external library projects which are still small enough to remain maintainable and reusable, but the main project seems to be impossible to keep organized.
Part of the problem seems to be that I have about 30 objects inheriting from a single abstract superclass type object. All of child objects have both a logic component and a ui component which are tightly integrated to each other. The superclass object has about 60 shared methods and properties, most of which can be overridden in any of the child classes, a few of which should be overridden in all child classes.
To add to the complexity, these have to communicate between themselves, and this is usually via the container object they reside in. Additionally, the main project has to create value objects out of these so they can be sent to a FlourineFX backend for storage, and additional authentication/authorization logic.
I've created much larger projects in languages from old MS BASIC (pre VB), Ada, VB (3 to .Net 1), C++, and C# without this problem. (well, old VB tended toward this problem because of the same tight integration between UI and logic) So, is there any thing I'm missing, or is there any best practices that I can implement? (even if that means rewriting entire swaths of code)
And yes, this may be an extension to this conversation.
Do you use any framework implementations in this project? A framework would help modularise a lot of this complexity and hopefully remove a lot of the dependencies you seem to have between the application logic and views.
I'm a massive advocate of the RobotLegs framework which implements the mvcs pattern and offers dependency injection for use throughout your project. There are others out there such as pureMvc, Cairngorm, Mate. Have a look around and see which best suits your project.
It sounds to me like you really need to do a big refactor which is a risky process in such a large project. It could be well worth it if you're struggling to maintain it. If you are going to refactor definitely refactor into a framework. It's probably the area that will give you most bang for your buck (pound for the brits ;) )
James Hay's conversation starter is a good one, but for HUGE applications I would take time to test and consider memory management for some of the suggestions in that answer/conversation. RobotLegs is great and all, but I would worry about 'over-singletonization' and potential memory management issues that it would create (though I have to admit that I've never used and avoided robotLegs because of it's use of singletons).
If you were thinking IoC and dependency injection (like that which robotLegs provides), I'd suggest a look at swiz -- I really like the new 'instance-direction' swiz has taken. My only issue with it (in the current beta) is they have some cleanup issues, though these issues are easy enough to remedy (look through their source and any time you completely remove a component from the stage you'll have to play the profiling game and make sure everything is getting cleaned up --- we had to create temp functions to remove the changewatchers and destroy 'display list bean instances' until they get that stuff fixed).
The project I lead had many of the potential issues you must be worried about. Our ERP app has thousands of modules and the thing is running on client machines for hours/days at a time, constantly loading and unloading modules. Garbage collection and memory management were and is THE issues.
As for using mate, the annoying carhorn, or pureMVC, we created our own framework two years ago. It borrowed ideas from cairngorm, but overall my suggestion is to use whatever you can quickly learn, understand and teach while thinking about garbage collection. Our internal Model and View classes now use swiz (for newly developed modules) and this has made maintainability and code readability super smooth.
I hope my blabbing has helped at least a bit.
Best of luck.
It seems like you just need a clean separation of UI and domain components. Look into the component guidelines and the Presentation Patterns discussed by Martin Fowler, especially the Presentation Model.
To bring these pieces together, you might want to use an IoC container like Spring ActionScript. This is a non-intrusive framework that allows you to keep layers separated.
Don't let a framework get in your way. I've seen massive misuse of frameworks like PureMVC and Cairngorm mainly because apply them in an all-or-nothing fashion.
I was toying with the idea of allowing module to with a class in a properties file ; something like
availableModules.properties
Contact=org.addressbook.ContactMain
Business=org.addressbook.BusinessMain
Notes=org.addressbook.Notes
...
My framework will use reflection to instantiate the relevant modules, and thereafter call methods on the relevant base classes, or pass the objects as parameters as required.
Is the above a good place to use reflection?
Are there any best practices on where to use reflection already posted on SO (I couldnt' locate one)? Could we start a list along those lines with any responses posted here?
EDIT
Here's another example of the kind of scenarios I have in mind.
Some core code needed to determine the point of call.
One application I saw achieved this by using reflection, another application used an exception. Would you deem the former to be a recommended scenario where reflection may be applied?
For a great framework supporting your idea have a look at the IOC container of the spring framework.
Is the above a good place to use
reflection?
I'd say no. If you want to do this kind of thing, you should probably be using one of the (many) existing mature frameworks that support Inversion of Control aka Dependency injection. Spring IOC is the most popular one, but there are many others. Google for "ioc framework java".
Underneath the hood, these frameworks most likely use reflection. But that doesn't mean you should reinvent the wheel.
I usually used reflection if I want to dynamically use a class which information (assembly name, class name, method name, method parameters, etc) are stored in a string (text files or database).