From: Clifford Heath <no@...>
Date: 2005-07-25T08:30:58+09:00
Subject: Re: Refactoring Tycho API - Opinions wanted

Kero wrote:
>>>I still don't see how that differs from a "view."
>>To me, a view is formed by a restructuring or simplification of the
>>subject material that is *externally applied* to the material. In
>>aspect-oriented modelling, the structure is built into the material.
>>A variable/value applies to an object *and* pertains to an aspect,
>>intrinsically, not because some viewer wants to see it that way.
> So, a ToDo item has a Period in which you want to work on it; and a
> period would be data from an Agenda aspect, really.

Exactly, good example. I would have a Scheduling aspect (Agenda is a
sub-aspect of that), and I would have an Activities aspect. The ToDo
item then crosses both aspects.

> In ruby duck-typing style, I wouldn't care about what is visible and
> not, so views and '(groups of) properties' are less strictly separated.
> That may not be so good for the current discussion.

True. The important thing for this is that the facets of an object
cannot change the nature of the base object. They can change the way
it behaves within the boundaries of its public interface, but it should
still *be* what it claims to be. I realise this is a question of static
vs dynamic typing, and I'm entirely sold on duck typing, but it isn't
a discussion I want to re-open here.

> Hm. I've played with the last method, in the past. Had to split up the
> agenda in history-per-year and future data, 'coz loading on iPAQ became
> slow.

Yes, that's the problem with large serial files - you can't update
without loading the whole file.

> Haven't thought of anything better, yet. rdbms
> maintainers build another index when stuff is 'too slow'. I don't think
> that's very scalable, especially for a handheld.

It's also the wrong answer in many cases, as it makes update slower.
You can't design good databases unless you understand how queries are
processed. I still have a dream one day of taking the transactional core
of a DMBS, for example "Shore", and building a truly aspect-oriented
database on it. When I tackled this in 1987, there were no DBMS
available in source, so I had to start from scratch. I failed, because
key techniques (like KVL etc) were unpublished trade secrets of the
DBMS vendors at that time.

Clifford Heath.