[kforge-dev] domainmodel API design suggestions

[Jo Walsh]

dear John, 
On Fri, Nov 17, 2006 at 05:51:30PM +0000, John Bywater wrote:
> task. But nevertheless, it is quite stupid to have things "poisoned" in 
> this way.

Is gloomy rhetoric like this really necessary? In an open process 
there are always going to be incidental situations where developers
commit changes that break tests for others (such as forgetting to 'svn
add' a file which does often happen.) The codebase isn't "poisoned" at
this point, it just needs getting back in line with its tests or its
test coverage improved. This happens. 

> 2. Degrading the quality of the system for no good reason: it is 
> system, other time will be consumed fixing up things afterwards.

Well, on the positive side there is MySQL support now, which opens up
to more potential users. A quite functional interim fix happened in a
few minutes. There was no necessity to take time at this point 
implementing a map for reserved words; I think an issue saying "just
don't use reserved words / fix this one day" and moving on with what
is in the plan, would have been a perfectly adequate response. 
Sigh, i mean i totally accept we were at fault in not making sure we'd
run the domainmodel tests as well as the ckan ones before committing
changes to domainmodel, i hoped that was clear last week.
 
> >   ...
> >   classes = application.classes()
> >   package = classes['Package']
> >   package.list(filter) or package.search(filter)
> 
> Which ideom is this? Do you have a name for it? Can you explain in which 
> context it works, which forces it resolves, what are the limits of its 
> applicability, why it pertains to the domainmodel package, and what the 
> other choices are available?

Why do i need a name for it? What do you mean by 'context' and 'forces'?
I intend this as a candidate for the style of thing i mean, not a
'this is how it should be' pronouncement. I'm puzzled by how broad
these questions are - i thought my suggestion was quite constrained. 
Why it pertains to the domainmodel package? because this is about
dm.application.Application's interface and how applications are built
on the not-a-framework? 

But right, what i wanted to do and was struggling to see how was
getting lists of DomainObjects right from the registry, rather than 
having to ask for a register of DomainClasses and start asking them
what instances they know about, i was just looking for the wrong thing.  
  
> Does it make sense to have the type of an instance be also responsible 
> for collecting the set of instances of that type? I think it can make 
> sense, but doesn't in our case:

So the code snippet Rufus sent earlier cleared this right up for me. 

    >>> app = ckan.getA()
    >>> tags = app.registry.tags  # or app.registry.projects or ...
    >>> tags_i_want = tags.filter(...)
> 
> We have a need to support two distinct responsibilities, and have 
> written two distinct system objects for this: the DomainObject class, 
> and the DomainObjectRegister class. Having one fall back onto the other 
> means that a DomainObject instance can't instantiate a collection of 
> aggregate domain objects without somehow producing an objective 
> confusion (which Spinoza defines as mixing two distinct concepts, such 
> as 'triangle' and 'square'; in our case 'type' and 'collection').

It would be a lot easier for me if you could illustrate what you mean
in code or pseudocode. E.g. an example of a DomainObject instance
trying or failing to instantiate a collection of aggregate domain
objects...? Is this saying that DomainObjects can be objects or they can be
sets, where 'instances can hold subsets of instances'?
How does this relate to what filter() is doing above?

> The requirements of the KnowledgeForge 
> service (with things such as members of a project) led to the 
> distinction I describe.

I don't see why that requires members to be a set though? (Forgive me
if this has been thrashed out and is documented in the archives) Say,
if this were at the SQLObject level directly i would use a
many-to-many mapping between projects and their members. 

> Summary: the domainmodel code makes a distinction between type and 
> collection, so that instances can hold subsets of instances without need 
> for further conceptual complexity. But we didn't implement delegation by 
> types to the collections of all instances of that type. But we can do that.

Okay, you have lost me now :) 

> I wouldn't necessarily say that there was an API at the moment. There is 
> a collection classes, each having responsibilities and collaborations, 
> and therefore holding several attributes and methods. And so there are a 
> number of de facto interfaces, but no API as such has been designed or 
> documented.

Right, well that is why i am interested in this discussion, as a
prospective application programmer i would like an application
programmer's interface, and would enjoy the opportunity to help design
it.  

> That having been said, the notes you made on "how to query for instances 
> of an object in the domain model" were based on my answering your 
> question of how to access what you referred to as "meta" data. That's 
> why I was steering you to the register of domain classes, each of which 
> hold a meta object that describes a type of domain object.
> 
> As you really want the model data as such, rather than the model meta 
> data, I would suggest taking a slightly different approach: use the 
> domain object registers that have been instantiated on the registry 
> directly (e.g. registry.projects).

Right, well i want both the model metadata and the instance data which
is metadata about other things (like geospatial data sets).  

> But the real way to go is to write down what you really want as a test 
> case. Then we can satisfy your test case. Then we can refactor to make a 
> better interface, probably first making a FACADE (not shouting: patterns 
> are often written in capitals). Creating a "better interface" first 
> isn't the way to do agile development, and therefore isn't the way to 
> work with the established grain of this project.
>
> I have do desire to discuss improvements to software systems without 
> reference to what that improvement is to adequate to, expressed normally 
> as a unit test, 

You don't want to have any software feature / interface discussions
without unit test up front expressing a suggestion? But there's always
going to be topic drift. In this case there was already a quite
adequate way of doing what i needed and i quite quickly found out
about it. 

I think this is too much enforcement; too high a bar. It's a nice
ideal and i definitely agree that it is fastest and most fun to fight
with code not with words. I would cheerfully write doctest into an
email and wonder whether that would be acceptable in order to persuade
you to discuss software suggestions and changes. 

> because the process doesn't complete, and is therefore 
> bound to be exhausting. I would like this to apply the idea of 
> adequation to discussion of the qualities of a software system: you say 
> it's baroque (ie overly complex?) but you don't say what you measure and 
> judge its complexity against.

Well, the judgement is personal about the heavy use of inheritance
hierarchy and multiple inheritance. I have shown bits of the design and
code to a couple of other programmers and they both had similar 
reactions to mine, and always conclude 'well i am sure it does work
very well'. I'm quite familiar with the application domain and have
built several similar 'not-quite-frameworks' along similar lines.
I know there has been a lot of roundabout discussion of the role of
the meta-model mapping layer and to what extent it is really necessary
to have one, and it will be really positive if that can be made to
support a range of ORMs and OODBs as well as SQLObject in the future.

And it is tempting to stay on the path of something that looks or
feels right even when that activity is yakshaving with regards to the
applications that one originally set out to get built. 

> If (as Ward Cunningham proposes) a program is a set of rules for solving 
> a problem in the future, and programming is a discussion about such 
> rules, then the first point of discussion may be that the near future 
> will be more similar to the near past than the distant future will be to 
> the distant past. Therefore it would make sense to shortcut understands 
> in the future with understandings from the past, and carry forward 
> things that work in the past (in a way that works) into the future, such 
> that we can give most of our attention to what is *different* about the 
> future ("embrace change").
> 
> To begin, if you can *see* the patterns, then I'm happy. Just to 
> clarify, the "raw pattern language" is in the black and red Martin 
> Fowler book, that you said you haven't read so far.
> 
> Perhaps you could find time to expose yourself to the real "raw pattern 
> language" of enterprise applications before we next meet? Then you will 
> be able to understand the application of enterprise applications that 
> has been made on this project over the last 18+ months.

Okay i will look at least at http://www.martinfowler.com/eaaCatalog/

But the patterns aren't an endpoint; they are a midpoint. I don't
think it's possible to take a set of patterns and mandate that they
are fine and therefore the complete system design is fine. The system
is as much about the people who interact with it, about the
interaction of different subsystems within it, more like in
http://en.wikipedia.org/wiki/Actor-network_theory

See also http://frot.org/zool/alexander.txt ... not having learned
your disciple i can't shed it, but perhaps it is something you might
bear in mind? ;P

> convinced that email has the bandwidth for a discussion of software 
> design that hasn't been dramatically compressed by the application of 
> design patterns.

Yes well perhaps this has the advantage that we *could* exchange more
code, even proper doctests here rather than veering off into
meta-level discussions which can take up a lot of time too :)

cheers,


jo
--