Posts

Showing posts from 2007

znPlugin 0.95 complete

Well, I haven't had much chance to work on znPlugin for a while, but version 0.95 is done. The reason this is not version 1.0 is that I am still looking for ways to optimize the code in accordance with my use cases. However, it has turned out quite well.

As I referenced in my last log, I had a good discussion with gneverov on http://cs.hubfs.net/. Near the end, you see a function posted that I wanted to incorporate into my code. However, that will no longer be possible because I have turned the Plugin Manager into a plugin factory. Thus, instead of creating and keeping objects around that may never be used, I create them on demand. The way I see it, if a user wants to get access to a previously created plugin, they should keep it around. Otherwise, they can always request a new copy.

I've also updated what constitutes a possible plugin, by making explicit the idea that it can be nested, as long as it is public. In addition, the implicit idea that a plugin must have a default (no…

znPlugin update -- discussion on hubFS

I've initiated two discussions at hubFS (Post 3806 and Post 3786) on some aspects on znPlugin. Specifically, the parts that relate to performing efficient type comparisons and casting. There are a lot of ideas in that thread, including some sample code. Post #3875 is particularly significant, as it is responsible for the latest changes in the framework.

The discussions have slowed somewhat, but they are still good reads for people interested in Reflection within F#.

znPlugin -- generic plug-in library

As I mentioned earlier, znPlugin is a generic plug-in library that allows developers to add such functionality to their applications / libraries without forcing them to conform to any pre-defined interfaces.

Some competing libraries / frameworks are listed below:
MSINC .NET Plugins Library - A library, written in 2004, that does exactly what I am trying to do. I've been going through the documentation, and it provides some great ideas of how to reach my goal.MSDN article - Food for thought on what needs to be taken into account when writing a robust library.TechRepublic - Use C# and the .NET Framework to develop your own plugin architectureCreating a Flexible Dynamic Plugin Architecture under .NET - They use XML files to store plugin information independent of the actual assembly. I did not opt for this approach, as it is extremely cumbersome to maintain an independent file unnecessarily.Task Plug-in: A Flexible .NET Plug-in Architecture - A good introduction to elementary plug-in a…

znOptions / znConfig update

Well, it's been a while since I've posted. First, some changes:
znOptions has been renamed to znConfig.The library has been redesigned to support more than one options style platform.Instead of hard-coding the save formats, I will use a plug-in architecture (more on this later).Second, I have found some additional resources that have provided additional inspiration and ideas:
Nini - As per the description, "Nini is an uncommonly powerful .NET configuration library designed to help build highly configurable applications quickly." Though I haven't used this library, reading the documentation seems to hold this up.libconfig - The description states, "Libconfig is a simple library for manipulating structured configuration files, like this one: test.cfg. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code." The type-aware part is interesting, though I'…

znOptions -- application options file library

Here is the first problem I want to tackle. I have, as yet, been unable to find a good options save/load library to manage application settings.

On the flip-side, I have found a very interesting post on MSDN describing exactly what I want to do. However, I have no interest in using the registry and aggressively advocate self-contained cross-platform projects (think Mono and Portable.NET). Thus, I will use the second method described on that page in order to create a more functional way to save and load settings while hiding the details from the developer.

Interestingly, there is an OCaml library named config_file, part of the Cameleon2 system, that does something exactly like this. The primary reason not to use this (other than it being the easy way out) is to learn more about F#'s interaction with the rest of the .NET API and to learn a little more about .NET's XML manipulation capabilities in the process.

Thanks and regards.

znProjects -- First post

Well, this is my first post on this blog (my first blog!). Hopefully, I can use this site to document my progression through learning and using F# and OCaml.

Feel free to browse the links on the right, especially the News and Comics sections. You can never be too well-informed or have enough to smile about :).

Have a good day!