Creating Extensions in MMF

At the Click Convention, Chris Branch spoke about creating extensions within Multimedia Fusion itself. I think this is a great idea, and I think that the Ini++ object is an example of why.

The Ini++ object is fundamentally very simple: It is an associated-array of associated-arrays of strings. However, data structures like that are not easy to work with in MMF, and so the object wraps at this up for you. It also includes other functions, for instance hashing, encryption, debugging dialog boxes and integration with object objects. Finally it has a load of actions which could theoretically be programmed yourself such as merging and searching.

So the Ini++ object really is not a difficult thing. So it should be easy to port it to Java and Flash and iPhone and so forth – but it isn’t.

The problem is, it is too big. There is a lot of code, and a lot of actions. Ini++ will never be ported. I wouldn’t want to anyway: The Ini++ v2.0 object (which to some degree exists, but has never been released) is so much more elegant. The original evolved, but this was designed. It is so much nicer. But I don’t have the time or will to work on that, let alone porting the original object.

But imagine this: Suppose the C++ (or whatever) component of Ini++ was very small. Maybe just based around a hash-table object which also had some features to do things which would otherwise be slow (sorting and searching for instance). Then all the features like ‘Merge into other Ini++ object’ and ‘Sort items of groups’ and so forth could be programmed in MMF itself. It is automatically portable! The difficulties are hidden from the user, but not put into my code. It is great!

It makes a lot of sense really. Somebody once wanted Ini++ to export to CSV. Have you ever used this feature? I bet you haven’t. I haven’t. So why should it be in the code? It is sitting there, making the object less portable, whilst adding absolutely nothing to nearly everybody else.

Saving the details of an object (as the ‘Save Object’ function does) would be positively better written in MMF. I assume what the internals of the object will look like, but that might change. Indeed, it has changed with the Unicode version of MMF – Saving alterable or global strings will only give you the first character. I guess I should fix that before the final Ini++ v1.5 release – I’ll put it on my list now. (Edit: The latest versions have fixed this.)

If it was coded in MMF, there would be no need for changes at all. It would be better. You might say there would be a loss of speed, but I doubt it’d be a big deal.

I think the elegance of the idea is brilliant. When MMF3 comes along, if it supports this feature I won’t be recreating an Ini++ type object directly. I will strip it down to its bare bones and make the rest within MMF3. It is much more elegant.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: