PureMVC Architects Lounge

Hi cliff

just wondering what you thought of the idea of having some kind of top level interface package in the utilities package.
I was thinking of future proofing issues... as in you have lots of people writing some great utils, and some way of promoting loose coupling between them would be great. I mean what happens if I want to use an existing util in one that I am writing, but don't want to couple it tightly to it, so they have to be used together.  Also common interface like IFactories and IEncodeables could use the same interface throughout the utils package.

this would of course need to be standardised and mediated.

i hope this has made sense.

what do ya think? :)

To get an idea of how two PureMVC utilities can interact, have a look at the the AIR utilities DesktopCitizen and XMLDatabase.

The former uses the latter to store its window metrics data to an XML file. If you look at the two AIR demos that use DesktopCitizen (CodePeek and RSSHeadlines), you'll see that CodePeek also uses the XMLDatabase utility to store your searches, but RSSHeadlines only uses DesktopCitizen.

The package space is controlled to ensure they don't conflict, so you can generally mix and match the utilities.

The problem with a global interfaces pacakage is that it will see continuous churn, and deciding what goes in and what stays out will become a tedious ongoing debate. For instance, 'IEncodeable'. What is that? I've never used it. Is it common, and I'm missing something? [A heated but arcane discussion ensues regarding the obvious importance of having an IEncodeable interface in any toolkit of repute]

Modifying or deprecating will be a pain to coordinate since and you'll have utilities and apps with growing dependencies on those interfaces. Like global variables, or 'common' libraries, they can become the broom closet everything gets stuffed into.

Also, if you only want to use an interface from another package, it's possible to set up svn:externals on a project to pull over the interface(s) from another project, into your own, for compilation and inclusion in your app or library. That way you don't have to copy/paste or include the entire library, or require that the other library be present in the app that uses your utility.

-=Cliff>

I did think that it might be a bit difficult to standardise, and you are quite right it probably would end in debate.
We are an opinionated lot

btw IEncodeable, I think is a java one, allowing recursive serialisation of collected value objects:

function encode():*
function decode(data:*)

but there are other ones that do the same but with different names...