DCT use cases - draft
Roman D. Boiko
rb at d-coding.com
Tue May 22 11:33:37 PDT 2012
On Tuesday, 22 May 2012 at 18:10:59 UTC, Jacob Carlborg wrote:
> On 2012-05-22 19:14, Roman D. Boiko wrote:
>
>> This is a draft of use cases for all DCT libraries combined.
>
> This seems to be mostly focused on lexing? See below for some
> ideas.
Yeah, about 50% is lexing. I pay more attention to it because
lexer alone is enough for several uses. I would like to have at
least some functionality used as early as possible, this would
provide me great feedback.
>> Scope for DCT is to provide semantic analysis, but not code
>> generation (that may become another project some time).
>> Information about projects, etc., is useful for e.g.,
>> analysing dependencies.
>
> That's a good point.
>
>> I'll improve overall structure and add some explanations +
>> examples
>> tomorrow. Could you elaborate on specific points which are
>> vague?
>
> I would probably have specified some high level use cases
> first, like:
>
> * IDE integration
> * Refactoring tool
> * Static analysis
> * Compiler
> * Doc generating
> * Build tool
Thanks! I didn't think about build tool, for exapmle.
I started this way, but after your comment on my previous post
that there is nothing new I reconsidered my approach and decided
to start from concrete (low-lewel), then improve it according to
feedback, and then split into areas (which roughly correspond to
your hi-level use cases).
> In general, use cases that can span several compile phases,
> i.e. lexing, parsing, semantic analysis and so on. Some of
> these use cases can be broken in to several new use cases at a
> lower level. Some examples:
>
> IDE integration:
>
> * Syntax highlighting
> * Code completion
> * Showing lex, syntax and semantic errors
>
> Refactoring:
>
> * Cross-referencing symbols
>
> Build tool:
>
> * Tracking module dependencies
>
> Doc generating:
>
> * Associate a declaration and its documentation
>
> Some of these "sub" use cases are needed by several tools, then
> you can either repeat them or pick unique sub use cases for
> each high level use case.
>
> Then you can get into more detail over lower level use cases
> for the different compile phases. If you have enough to write
> you could probably have a post about the use cases for each
> phase.
Thanks for examples.
> It seems some of your use cases are implementation details or
> design goals, like "Store text efficiently".
Actually, many of those are architectural (although low-level),
because they are key to achieve the project goals, and failing in
this area could cause overall failure. I intend to move any
non-architectural information into a separate series of posts,
feel free commenting what you don't consider important for the
architecture (probably don't start yet, I'm reviewing text right
now).
> It would not be necessary to start with the high level goals,
> but it would be nice. The next best thing would probably be to
> start with the use cases compiler phase you already have
> started on, that is lexing, if I have understood everything
> correctly.
Yes, and even before that I'm going to document some fundamental
primitives, like immutability and core data structures.
More information about the Digitalmars-d
mailing list