Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: top level Interface pakage for utilities  (Read 3432 times)
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« on: October 05, 2008, 08:53:31 »

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? :)
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: October 05, 2008, 11:13:16 »

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>
Logged
Neil Manuell
Courseware Beta
Sr. Member
***
Posts: 109


View Profile Email
« Reply #2 on: October 05, 2008, 11:22:26 »

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...
Logged
Pages: [1]
Print