Re: Status of refactoring discussion

From: Vladimir Prus (ghost_at_[hidden])
Date: 2003-05-14 08:44:40

[moving to the list, I think there's no problem with it]

> > I just wanted to make sure we all agree what remaining discussion is most
> > important now --- in order that you're not blocked waiting for emails to
> > cross timezones.
> >
> > Unless I've missed something, there were no big disagreements, except
> > for:
> >
> > 1. Removal of 'typed-target'. As I've told in email sent to jamboost
> > yesterday, I believe deriving from basic-target allows for more
> > flexibility than generators could, so I don't like the idea to collapse
> > the hierarchy rooted in basuc-target. OTOH, maybe the content of
> > 'typed-target.construct' can be moved to 'basic-target.construct' (which
> > is now empty). After all, current 'typed-target.construct' body is the
> > default behaviour. If we do that, 'typed-target' class can be removed.
> > Basically, I'm waiting for comments from either of you (but please post
> > them to list).
>
> If we do that, we also need to rename "construct". It doesn't
> construct the class; it's more like "build-dependency-graph."

It constructs the dependency graph ;-) I'm not sure if 'build' is any better 
than 'construct'. Count me as -0 on this.

> > Dave's idea to merge both hierarchies looked neat, but now I really
> > don't think it's possible. Current virtual-target is needed *only*
> > because Jam builtin targets are weak --- esentially there's the
> > targets we are concerned about (and renaming virtual-target to
> > target only stresses that).
>
> I agree with the second sentence but I don't see how it has any
> relationship to the first sentence. If the merge is impossible, I
> don't see why/how.

The first statement follows from the second and the following one...

> > Projects and main targets, OTOH, are just named entities which can
> > be used to create different variants of ordinary targets.
>
> Not *just* named entities; there should also be a real Jam target
> (and thus, a virtual target) associated with each of these things so
> that its build can be requested.

No! What you say is contrary to what is now and what we've discussed 
previosly: if you request a build of specific main target, we don't create 
entire dependency graph and then only update part of it. We create only the 
dependency graph for this main target. Technically, we take a project-target,
call it's 'generate' method and get all the virtual targets we need. 

This pretty much work, so I don't buy your argument that real Jam target 
should be associated with projects and main targets. So, I think there's very 
little in common between the two kinds of target.

A littlbe bit more:
- The 'generate' method from 'abstract-target' does not make any sense in
'virtual-target'. The latter corresponds to a file, built with specific
properties. You can't ask a file to change its properties.
- The 'actualize' method from 'virtual-target' makes little sense in 
'abstract-target'. Yes, you can make it create and return jam target for the 
project. But it must depend on all variants of all targets in the project, to 
be usable. That means you must pass all requested properties to it.

IOW, to merge the hierarchies, you'll need base class with some polymoprhic 
methods. Can you give signatures of those methods?

- Volodya