Thanks for your comments.
>
> Comments:
>
> - I didn't understand how the File interface is supposed to be used. The
> methods to parse and write the file appear both in the File interface, and in
> the Manager interface.
The methods in the File interface are supposed to be used by only
the Manager interface. We could hide it from the interface if it is confusing.
>
> Some questions:
> Will every element in the appication model have an associated file where it
> wants to be saved? I am imagining that a model (application + task +
> presentation + everything else) will consist of perhaps many files. Something
> in the model server needs to know where each object goes. This gets more
> complicated when you load in models for several applications. Maybe the way
> to structure things is using modules: a developer can say "save all objects
> for module X" and all the associated files are saved. A developer can also
> say "save file F" or "save the file that contains object X". We need to think
> about this.
>
> On the load side, a developer needs to be able to say "load module X". Maybe
> we need to keep a repository of modules. Do we need something like makefiles
> or project files so that things are loaded in an orderly fashion. How about
> "require module" statements or include "statements"?
Each object should be associated with a File. I am not sure, where
this association should be specified. Object creation might be too early.
e.g. if we want to create an interface, we need to specify the File with
which it is associated. But, later if we make it part of a module, which
is associated with a different File, then which one overrides which? This
can probably be resolved using a convention. But, the File didn't have to
specified in the first place if the only intention of creating the interface
was to add it to a module. I am still thinking about this problem. I would
welcome any suggestions from you.
>
> - I think we are not in sync wrt to the iterators. I was thinking about
> iterators similar to the ones in Amulet. The start, next, last, length
> methods are generic (returns void or ints or booleans). The only method that
> needs to be type specific is get, which returns the current object in the
> iterator.
>
> So in the presentation model we were assuming that there is an interface
> called Iterator that defines the generic interface for all (or most
> iterators). Specific iterators inherit from Iterator, and only need to define
> a get method that returns the particular type of object needed. One can also
> define additional get methods to get additional information about the current
> element of the iterator (eg when iterating over an array, get returns the
> current value, and get_index returns the current index).
>
I think there is not much difference in terms of functionality
with either of the implementations. As I see it, the way you think of it
is as follows.
interface iterator {
void start();
void last();
void next();
void prev();
short length();
};
interface short_iterator : iterator {
short curr();
};
interface long_iterator : iterator {
long curr();
};
The disadvantage with this implementation is that to access
an element we need 2 operations e.g. start(), curr(), or next(), curr().
When I think of iterators, I think of it as parameterized using the data
type. e.g. Iterator(short), Iterator(long) etc. Since, IDL doesn't have
parameterized data types, it had to be faked with macros. In terms of
code generated, I don't think there will be much difference between the
two cases.
-jk