[Grace-core] Fwd: Some notes on pattern matching on the wiki

[Ewan Tempero]

Ok, what I want for modules is to support Architecture level design. By this I mean to be 
able to describe "components" in Krutchen's Development View or "modules" in the Bass, 
Clements, Kazman module architecture structures. I teach from BCK so I tend to follow 
their view. Basically, a module is a unit of architecture description, and a unit of 
encapsulation. So the important thing is what the interface of a module is, and how it is 
described. Examples of the kinds of things BCK consider part of the interface description are:
* identity (modules can have multiple identities)
* resources provided, including functionality (ideally some semantic information), 
restrictions (e.g. security behaviour)
* resources consumed (eg time, memory, other quality attribute information)
* deployment information
(and more).

I'm not suggesting grace modules should do all this, but this is what I'll be thinking of 
when looking at proposals.

I don't think what I've said is inconsistent with what Andrew wants.
cheers
--ewan

On 08/07/11 09:52, Andrew P. Black wrote:
> What /I/ want a module m to do is package up:
>
> 	a collection of new objects
> 	a collection of new factories (which are, of course, just a special cases of the above), and
> 	a collection of new types (which may also be a special cases of the above!)
> 	
> These will need to be named in a way that separates them from other stuff that I may have named: m.obj and m.fact provide a great way to do this.   They will also need to be dependent on other modules, which are given to m as arguments.  (So, for example, m.Dictionary might depend on an argument to m that is a Set.)
>
> Others may have different desiderata for modules.  I think that we will reach closure on this faster if we first talk about what they are /for/.  If our purposes can't be accomplished with objects, then we should certainly invent something else.  Otherwise: concepts "should not be multiplied beyond necessity"!
>