-
Notifications
You must be signed in to change notification settings - Fork 10
Wish List
Features that I want as a programmer. Some of these features belong in LoycCore, but mainly I'm just wishing.
Given a method like
void Foo(string title = "", int size = 100, string[] files = null);
There should be a feature in the Loyc Libraries that
- Generates a GUI with "Title:" and "Size:" text boxes and an editable list box labeled "Files:". Then you click a "Foo" button to run.
- Generates a CLI that accepts a command like
program Foo --title:Hello --files X.txt Y.txt
Basic customizations to the GUI could be supported via attributes.
The Ambient Service Pattern makes it possible to improve or replace standard services like file access. Sadly the .NET BCL mostly does not use this pattern, but we could create parallel APIs that are extensible and replaceable.
File access should have a "simulation" mode that lets a programmer find out what his program will do to the file system (renames, deletions, creations) without actually doing it.
It would be neat if someone could adapt at least three GUI libraries to a single common interface, so that it is possible to use the same code to create, inspect, and manipulate widgets from different GUI libraries.
As a separate matter, I'd like to see a slick new GUI library that
- Has a fully automated animation system so that common operations are animated with little or no effort from the developer, e.g.
- "expanding" a list box item into a view/edit screen for that item
- when sorting a list or adding/removing an item, the old list animates into the new list
- return of the Mac: when pressing a shortcut key, the applicable toolbar item and/or menu flashes briefly
- scrolling beyond the end of a list and snapping back
- Provides clever design tools that allow developers to more easily create interfaces that scale from telephone screen sizes up to laptop screen sizes, and from tablet to mouse interfaces.
- Uses screen real estate efficiently "by default" with not much work from developers. Example: "toolbars" that float in the corner of a list box or view/edit area so that there is no wasted space on a dedicated toolbar area that isn't full. The list should enlarge its scroll extents so that the user can always uncover content hidden underneath overlapping widgets.
- Has a modular, flexible, and easy-to-use system for composing list controls, so that it's easy to set up lists in a variety of different ways. Multi-column lists and tree views must be supported in a single control.
- Has a modular, flexible, and easy-to-use system for composing free-form viewing and editing controls (e.g. document viewers, paint programs, diagram editors).
- Incorporates simplified forms of HTML/CSS, especially the box model.
Primarily useful for GUIs but also useful for nontraditional databases, declarative reactive programming means that you "declare" the value of "dependent variables" in terms of other variables, including possibly in terms of queries on collections. Often, dependent variables are GUI states such as the contents of a list box or whether a button is enabled or not. When the dependencies change, the "dependent variables" change automatically, in contrast to the traditional push model where change propagation happens manually.
The best system I know of so far is Update Controls. However, its debugging features (which I wrote myself) are limited, and it has a scalability problem whenever collections are involved (in two parts: (1) collections are always modeled as if they were single variables, so any situation with large collections is inefficient, and (2) change propagation is unstoppable which exacerbates the first problem). A third issue is that it is very "magical" and relies on hidden global state to set up relationships between parts of an application. The last issue is probably best solved by having some kind of support in the programming language, or via macros.
The popular React.js framework by Facebook is a hybrid immediate-retained UI framework. This kind of system looks like it could work just as well as a DRP system, and since it has less "desire" for compiler support, it would work well in any programming language, and in theory, at least, it could be adapted to existing GUI systems like Windows Forms. Since it was popularized by Facebook, I'm betting on this horse, since anything made by a big company automatically wins more popularity than anything that wasn't.
There's a ton of old .NET APIs with odd and crufty interfaces that Microsoft refuses to update. For example, there are a crapton of XyzCollection classes that hold Xyz objects but do not implement IList<Xyz> and in many cases do not even implement IEnumerable<Xyz>. Some of these are read-only but implement IList; others are read-write but do not implement IList. It's a mess. Something should be done about it.
ADO.NET needs updates too (the newer alternatives are enormous; ADO.NET remains the best fit for simple jobs.)
The reflection library is certainly ripe for modernization, although mostly the ball is in MS's court (no one else can eliminate the inefficiencies in the current Reflection libraries, for example). But perhaps it would be possible to modernize the reflection APIs to make them easier to use and more general (e.g. the standard reflection APIs, which can only manipulate runnable code, should be nearly identical to APIs for manipulating code purely as data, e.g. Cecil--there should be a set of common interfaces for both. I know that somewhere out on the internet there is a rather long-winded article about "mirrors" which are basically reflection APIs designed more modularly.)