gearwerk-worker

Parts

[Thorsten H. <gea...@th...>]

Hi,

I'm still fond of the Part hierarchy. Here's why:

- First of all, Part *feels* right. This may sound weird, but I think
  it is useful for a designer to have a good intuitive grasp of the
  major objects and object structures. I also think that Parts are a
  natural part of the problem domain, ie. it is natural to think of
  Vehicles consisting of parts.

- A Part is, by definition, very cohesive.

- Parts make very good models for Model/View Seperation. We already
  have several views and might easily find more. Design option could
  be changed according to a vehicle type I choose at design start.

- TV calculation would be internal, so all optimization (caching)
  would depend on actual need. The same principle applies to other
  data which might require special consideration.

- Support for later, earlier or just different rule sets would be
  simpler. Games like these often have tactical rules, which could be
  implemented more easily.

- Since Parts are supposed to save themselves we'd get instant deltas.
  Just right-click on that weapon/perk/ammo combo Part, save (or put
  them in the clipboard) and to move it over to the other vehicles of
  your squad.

- I don't see that Parts are that complicated. Where do you see
  problems for the implementation?

- There is actually no recursion involved, just the domain-space
  relation of things to each other.

- Multi-part vehicles would be hassle-free.


Some comments about the alternatives as I understand them:

- Expert classes for saving, printing etc. would need internal
  knowledge about most part of the vehicle. This breaks encapsulation
  and would almost probably provide for very high coupling.

- The class controlling most of the vehicle would be very sensitive to
  creeping featurism.


Interface vs. Abstract Class

- Again the feeling: The basic idea of a Part is interfaceish for me.
  I think of abstract classes much later in the development process,
  where it is used to factor out stuff.

- We could easily provide a (non-GoF) Adapter class like Swing and SWT
  do for their Listeners.

- An abstract class wouldn't be that useful. TV calculation is
  different for each Part, other stuff even more so.

- (referring to Adam's mail) Interfaces are often used where multiple
  inheritence wouldn't make sense. Deriving a class is the thing to do
  if you have common functionality or another reason to share code.
  Interfaces are just big advertising signs making promises.

  Even many uses of abstract classes in GoF are really interfaces. Two
  implementations of an Abstract Factory are not meant to share much
  code (think toolkits).

- There is a natural limitation in using Interfaces: You have to
  implement every Interface methods in every class. If you heap dozens
  of Interfaces on a class, you will notice.


Thorsten
-- 
So this is what we're sacrificing liberty for: a phenomenon that
is typically less than 0.1% of the threat from auto accidents,
and didn't even break 10% in the worst year ever.
    - e_lehman

Re: Parts

[Jake S. <Ja...@bi...>]

On 12/11/2004, 19:48, Thorsten Haude wrote:

> - Parts make very good models for Model/View Seperation. We already
>   have several views and might easily find more. Design option could
>   be changed according to a vehicle type I choose at design start.

(This part, to me, seems an important thing to bear in mind, e.g.
considering things like the board game adaptation that George
mentioned or the fact that we're naturally going to be making
interface decisions and people may not agree and want to write their
own alternative UI)

> - Since Parts are supposed to save themselves we'd get instant deltas.
>   Just right-click on that weapon/perk/ammo combo Part, save (or put
>   them in the clipboard) and to move it over to the other vehicles of
>   your squad.

Along a similar thread, I expect that it would make the idea of
undo/redo easier to implement if we can just request a description of
a change from a single known interface?

> - There is actually no recursion involved, just the domain-space
>   relation of things to each other.

Well, walking a tree feels a lot like recursion to a lot of people;
it's easier just 'cause you don't have to worry nearly so much about
termination conditions and the like 'cause the tree structure just
naturally sorts that bit out for you, but it's a similar concept. What
goes on inside the node class could just as easily be a recursive
function outside of the node working recursively through an
interface...

> - Expert classes for saving, printing etc. would need internal
>   knowledge about most part of the vehicle. This breaks encapsulation
>   and would almost probably provide for very high coupling.

Similarly, I'm also of the opinion that this is a bad thing.

> Interface vs. Abstract Class

> - We could easily provide a (non-GoF) Adapter class like Swing and SWT
>   do for their Listeners.

(Really do need to get around to reading that book sometime... ;-)

> - An abstract class wouldn't be that useful. TV calculation is
>   different for each Part, other stuff even more so.

Mmm, but things like walking through the tree of parts and aggregating
the results of the 'calculate my TV' call could be implemented in an
ABC, and I don't know about your experience but I've found it easier
in the past to change an inadvised ABC into an interface at a later
date than vice-versa.

> - (referring to Adam's mail) Interfaces are often used where multiple
>   inheritence wouldn't make sense. Deriving a class is the thing to do
>   if you have common functionality or another reason to share code.
>   Interfaces are just big advertising signs making promises.

(To give an example, my native C# has an "IEnumerable" interface (I
know Java has something similar, I just can't remember offhand what
it's called) which binds the class to ... well, being enumerable, it
supplies the correct method to allow sugar structures like foreach to
work properly with the class in question. This wouldn't make any sense
as a multiply-inherited ancestor as enumerating is inherently very
class-specific; a queue and a connected dataset are empirically
enumerable but completely different things are going on if you
actually ask them to enumerate.)

> - There is a natural limitation in using Interfaces: You have to
>   implement every Interface methods in every class. If you heap dozens
>   of Interfaces on a class, you will notice.

...and for that very reason, I have a natural [lazy] aversion to using
them unless they actually have advantages over an ABC, so take
anything I say on the subject with that pinch of salt in mind. ;-)

-- 
Jake

Re: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 20:18:03 +0000, Jake Staines <ja...@bi...> wrote:
> On 12/11/2004, 19:48, Thorsten Haude wrote:
> > - Parts make very good models for Model/View Seperation. We already
> >   have several views and might easily find more. Design option could
> >   be changed according to a vehicle type I choose at design start.
> (This part, to me, seems an important thing to bear in mind, e.g.
> considering things like the board game adaptation that George
> mentioned or the fact that we're naturally going to be making
> interface decisions and people may not agree and want to write their
> own alternative UI)

Which is why we separate our data from our interface. This doesn't
necessarily require Thorsten's parts hierarchy. The alternative one
that I suggested is just as good here.

> Along a similar thread, I expect that it would make the idea of
> undo/redo easier to implement if we can just request a description of
> a change from a single known interface?

The Parts hierarchy doesn't really help here, either. We still need
some kind of format for storing a list of operations performed and
applying/unapplying them as necessary.

> Well, walking a tree feels a lot like recursion to a lot of people;

That's because recursion is often used to walk a tree. Even if you
unroll it in the implementation, you're still employing a recursive
algorithm. We don't need that here, as vehicles are very shallow.

> > - Expert classes for saving, printing etc. would need internal
> >   knowledge about most part of the vehicle. This breaks encapsulation
> >   and would almost probably provide for very high coupling.
> Similarly, I'm also of the opinion that this is a bad thing.

Right, but there's no greater or lesser coupling from using Parts. The
interface, saving, printing, etc. still needs to know how to get the
Armor. It still needs to know how to get a list of Perks, etc.

-- 
-Nick Pilon

Re[2]: Parts

[Jake S. <Ja...@bi...>]

On 12/11/2004, 20:25, Nick Pilon wrote:

> That's because recursion is often used to walk a tree. Even if you
> unroll it in the implementation, you're still employing a recursive
> algorithm.

I'd argue that it's not really recursion unless you're calling into
the same method on the same class recursively, what we're suggesting
with Parts is calling into the same interface on different classes,
which negates half of the difficulty with recursion... but it's a moot
point.

>  We don't need that here, as vehicles are very shallow.

Oh are they? From what I remember, a common-sense, 'normal'
interpretation of the contstruction rules in SilCore suggests that
they are /mostly/ fairly shallow, but that a OO programmer's reading
of the same rules would have them as anything but. Could you, for
instance, build a combined vehicle for which one of the parts is a
multi-section vehicle for which one of the locations is transforming?
You mentioned yourself earlier the idea of a multi-section with a
transforming motive section, if you're going to open that can of worms
then the vehicle tree is as deep as the user wants it to be.

Now sure, you can say that that's really a tree of trees, and the
external tree is deep and the internal trees on each node shallow, but
the other thing to bear in mind is that in my experience more
generically-coded classes make debugging in this sort of situation
easier.




(For that matter, can you have:

a) a transformable vehicle for which one but not all of its modes are
multi-section?
b) a combination vehicle that can transform into non-combination
modes?
)

-- 
Jake

Re: Re[2]: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 21:47:15 +0000, Jake Staines <ja...@bi...> wrote:
> Oh are they? From what I remember, a common-sense, 'normal'
> interpretation of the contstruction rules in SilCore suggests that
> they are /mostly/ fairly shallow, but that a OO programmer's reading
> of the same rules would have them as anything but. Could you, for
> instance, build a combined vehicle for which one of the parts is a
> multi-section vehicle for which one of the locations is transforming?
> You mentioned yourself earlier the idea of a multi-section with a
> transforming motive section, if you're going to open that can of worms
> then the vehicle tree is as deep as the user wants it to be.

Yes, but read my other message - I address every single one of these
concerns there. We do NOT handle this within individual sections, nor
should we do so. We handle this by aggregation of sections.

Also, vehicle perks/flaws, vehicle movement types, vehicle systems,
and system perk/flaws have next to nothing in common. Why should they
be forced to use a common interface for the sake of making our design
look nicer?

-- 
-Nick Pilon

Re: Parts

[Thorsten H. <gea...@th...>]

Hi,

* Nick Pilon wrote (2004-11-12 21:25):
>> > - Expert classes for saving, printing etc. would need internal
>> >   knowledge about most part of the vehicle. This breaks encapsulation
>> >   and would almost probably provide for very high coupling.
>> Similarly, I'm also of the opinion that this is a bad thing.
>
>Right, but there's no greater or lesser coupling from using Parts. The
>interface, saving, printing, etc. still needs to know how to get the
>Armor. It still needs to know how to get a list of Perks, etc.

I don't see how they would need more than the top Part. Let's take
your first example, saving:

public class DocSaver
{
    yadda yadda;
   =20
    rootPart.save(fileWriter);
}

Part would of course have

    public void save(Writer writer);

Any Part with subParts would do something along these lines:

    public void save(Writer writer)
    {
        saveMyself(writer);
        foreach part in myParts
        {
            part.save(writer);
        }
    }

I realize that this is the easiest case, but I don't see that the
other cases would necessarily increase coupling. Ignoring Layout for
the time being:

public class SpecificPartView
    extends ContainerWidget
{
    private SpecificPart myPart;

    public SpecificPartView(SpecificPart newPart)
    {
        myPart =3D newPart;

        foreach part in newPart.getSubParts()
        {
            ContainerWidget.add(part.getWidget());
        }
    }
}


Thorsten
--=20
If something is so complicated that you can't explain it in
10 seconds, then it's probably not worth knowing anyway.
    - Calvin

Re: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 22:57:07 +0100, Thorsten Haude
<gea...@th...> wrote:
> >Right, but there's no greater or lesser coupling from using Parts. The
> >interface, saving, printing, etc. still needs to know how to get the
> >Armor. It still needs to know how to get a list of Perks, etc.
> I don't see how they would need more than the top Part. Let's take
> your first example, saving:

The issue I see there is that it looks like Parts need to know about
how they get written in order to write themselves. You're going to be
writing things quite differently for a graphical record sheet, an HTML
page, an XML save-file, and a DP9 vehicle block. Better, I think, to
provide methods for navigating whatever hierarchy we have set up, and
then have external output writer classes that know how to navigate it
and find what they need.

-- 
-Nick Pilon

Re: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 20:48:35 +0100, Thorsten Haude
<gea...@th...> wrote:
> - I don't see that Parts are that complicated. Where do you see
>   problems for the implementation?

The problem is that, as described, they don't reflect the underlying
structure of the VCS particularly well. Vehicles aren't composed of
parts, they're composed of a very specific, definite list of things.
If you insist on the "everything that is a part has a TV" abstraction,
the only things that are, properly speaking, parts are entire vehicles
or, possibly, everything but Perks/Flaws. And since vehicle and system
Perks/Flaws are both the only really dynamic part of the vehicle and
the most difficult to handle, I just don't see what it gets us.

(In fact, it doesn't handle system perks/flaws at all, as they're
multiplicative, like maneuver or accuracy)

Also, all the lines use the same rules now. So we don't need nor do we
want to go to the headache of supporting the older rules.

> - Expert classes for saving, printing etc. would need internal
>  knowledge about most part of the vehicle. This breaks encapsulation
>  and would almost probably provide for very high coupling.

Well, yes, but I don't see how parts FIX this. A graphical record
sheet STILL needs to know how to get a vehicle's armor value, or a
list of its movement types, or what-have-you. Perk/Flaw objects, of
course, would have control over how they're printed, and provide a
bunch of standard forms (VIA an interface and functions) that would be
used by the expert classes to represent the Perk/Flaw object.

> - The class controlling most of the vehicle would be very sensitive to
>  creeping featurism.

This isn't a valid objection. Any class structure is always sensitive
to creeping featurism, whether its localized to one class or spread
out across multiple classes. Since we've got a very small, limited
problem domain here, this isn't a very big risk.

-- 
-Nick Pilon

Re: Parts

[Thorsten H. <gea...@th...>]

Hi,

* Nick Pilon wrote (2004-11-12 21:21):
>On Fri, 12 Nov 2004 20:48:35 +0100, Thorsten Haude
><gea...@th...> wrote:
>> - I don't see that Parts are that complicated. Where do you see
>>   problems for the implementation?
>
>The problem is that, as described, they don't reflect the underlying
>structure of the VCS particularly well. Vehicles aren't composed of
>parts, they're composed of a very specific, definite list of things.

There must be some level at which individual Perks can be handled. At
this level, Part comes in.

For the other parts, they are of course fixed or we would have to
supply pretty many classes implementing Part. They are not identical
however, and (again projecting from HG) small details are everywhere.
(Is there a stall speed for ground movement?)

So while P&F might be the most dynamic, they are not the only thing
that moves in a vehicle.


>If you insist on the "everything that is a part has a TV" abstraction,
>the only things that are, properly speaking, parts are entire vehicles
>or, possibly, everything but Perks/Flaws.

Well, "everything but" doesn't sound too bad.


>(In fact, it doesn't handle system perks/flaws at all, as they're
>multiplicative, like maneuver or accuracy)

Not individually, at least not in HG. The multiplication would be done
by the parent Part.


>Also, all the lines use the same rules now. So we don't need nor do we
>want to go to the headache of supporting the older rules.

We may not want now, but we shouldn't necessarily choose a design that
makes it impossible for the future. Anyway, this is a minor point.


>> - Expert classes for saving, printing etc. would need internal
>>  knowledge about most part of the vehicle. This breaks encapsulation
>>  and would almost probably provide for very high coupling.
>
>Well, yes, but I don't see how parts FIX this. A graphical record
>sheet STILL needs to know how to get a vehicle's armor value, or a
>list of its movement types, or what-have-you. Perk/Flaw objects, of
>course, would have control over how they're printed, and provide a
>bunch of standard forms (VIA an interface and functions) that would be
>used by the expert classes to represent the Perk/Flaw object.

These non-Part Perk/Flaw objects, movement systems, armor, sensors and
all the other things have either something in common (which makes them
something we could call Parts) or the Expert would have to be coupled
to every single one of them, and would have to have domain knowledge
about each one of them.

Since I picture Parts as models, they would certainly need a view
each. These views would be much lower coupled however, and would much
better fit the object structure we choose for the whole vehicle. If
expert functions are still required for painting, they could be
provided by utility classes or inheritence.

A Part is only coupled to
    - its sub Parts
    - its views

A view is only coupled to
    - its Part
    - Utility classes


>> - The class controlling most of the vehicle would be very sensitive to
>>  creeping featurism.
>
>This isn't a valid objection. Any class structure is always sensitive
>to creeping featurism, whether its localized to one class or spread
>out across multiple classes. Since we've got a very small, limited
>problem domain here, this isn't a very big risk.

In the Part scheme, we wouldn't have a single controller that provides
most of the functions we require.


Thorsten
--=20
Those who do not remember the past are condemned to repeat it.
    - Georges Santayana

Re[2]: Parts

[Jake S. <Ja...@bi...>]

On 12/11/2004, 20:21, Nick Pilon wrote:

> On Fri, 12 Nov 2004 20:48:35 +0100, Thorsten Haude
> <gea...@th...> wrote:

> Also, all the lines use the same rules now. So we don't need nor do we
> want to go to the headache of supporting the older rules.

No, but personally I see no need to make it any more difficult than it
would be already to update the code for SilCore v4... I wouldn't go
out of my way to make the whole absolutely as generic as possible, but
I believe it's reasonable to make it as generic as we can without
making it harder for ourselves.

>> - Expert classes for saving, printing etc. would need internal
>>  knowledge about most part of the vehicle. This breaks encapsulation
>>  and would almost probably provide for very high coupling.

> Well, yes, but I don't see how parts FIX this. A graphical record
> sheet STILL needs to know how to get a vehicle's armor value, or a
> list of its movement types, or what-have-you.

That kind of thing can be solved by interface implementations... the
idea is to reduce the amount of knowledge the expert needs as much as
possible, move as much code as possible into the core classes that
everything's using to avoid
a) copy and pasting too much code between the printer and the TV
   calculator and the text-output and the XML save experts and the...
b) having opaque and complex expert classes that do the vast majority
   of the work when the Vehicle class itself does nothing but store
   data.

Fundamentally, it's the difference (IMO) between programming in an OO
model (where you want the 'Vehicle' class to know as much as it can
about itself and its own structure and do most operations on its own)
and the old procedural model (where the 'Vehicle' class would be
nothing more than a data structure for storing values and the
'program' would do /all/ work).

-- 
Jake

Re: Parts

[Thorsten H. <gea...@th...>]

Hi,

* Jake Staines wrote (2004-11-12 21:18):
>On 12/11/2004, 19:48, Thorsten Haude wrote:
>> - Since Parts are supposed to save themselves we'd get instant deltas.
>>   Just right-click on that weapon/perk/ammo combo Part, save (or put
>>   them in the clipboard) and to move it over to the other vehicles of
>>   your squad.
>
>Along a similar thread, I expect that it would make the idea of
>undo/redo easier to implement if we can just request a description of
>a change from a single known interface?

I haven't thought about that before. Parts should be as light as we
can manage though, so undo might better be put somewhere else.

I can't think of anything right now, but this should go on the list.


>> - There is actually no recursion involved, just the domain-space
>>   relation of things to each other.
>
>Well, walking a tree feels a lot like recursion to a lot of people;
>it's easier just 'cause you don't have to worry nearly so much about
>termination conditions and the like 'cause the tree structure just
>naturally sorts that bit out for you, but it's a similar concept.

It doesn't feel that way for me, but I see that the might look similar
=66rom the outside.


>> - We could easily provide a (non-GoF) Adapter class like Swing and SWT
>>   do for their Listeners.
>
>(Really do need to get around to reading that book sometime... ;-)

Absolutely, it's a must. I assume there are some overview about the
GoF patterns around, because they are really handy discussing stuff.


>> - An abstract class wouldn't be that useful. TV calculation is
>>   different for each Part, other stuff even more so.
>
>Mmm, but things like walking through the tree of parts and aggregating
>the results of the 'calculate my TV' call could be implemented in an
>ABC, and I don't know about your experience but I've found it easier
>in the past to change an inadvised ABC into an interface at a later
>date than vice-versa.

(What is an ABC? Abstract class?)

Interface to abstract class could be done with a moderately clever
shell script. It's not that easy once you have to move methods around.


Thorsten
--=20
War is God's Way to teach geography to Americans.

Re[2]: Parts

[Jake S. <Ja...@bi...>]

On 12/11/2004, 20:32, Thorsten Haude wrote:

> (What is an ABC? Abstract class?)

Sorry, yeah; "Abstract Base Class". I'm sure there's probably some
Design Pattern name for the methodology that I'm currently unaware
of... ;-)

> Interface to abstract class could be done with a moderately clever
> shell script. It's not that easy once you have to move methods around.

Well, the point was that in an ill-advised abstract class you wouldn't
have any methods to move around... if you've got implementation in the
base class then it probably shouldn't be changed into an interface.

-- 
Jake

Re[4]: Parts

[Jake S. <Ja...@bi...>]

On 12/11/2004, 21:58, Nick Pilon wrote:

> Yes, but read my other message - I address every single one of these
> concerns there. We do NOT handle this within individual sections, nor
> should we do so. We handle this by aggregation of sections.

Well, you seem to suggest more or less exactly the same thing, only at
a 'vehicle' level instead of a 'part' level; that there should be a
'GetTV' method at the topmost node that calculates its own TV then
calls 'GetTV' on each of its component vehicles or sections. Same
idea, we're just proposing using the same ultimate base class for
systems as well at the very least. I'd be tempted to call the
'collection of perks' part a Part, as well, for instance, since
essentially IIRC it just counts how many items it has (with a couple
of special cases, true) and returns that as a single value.

> Also, vehicle perks/flaws, vehicle movement types, vehicle systems,
> and system perk/flaws have next to nothing in common. Why should they
> be forced to use a common interface for the sake of making our design
> look nicer?

Well, they kind of have something in common, in that they all have an
impact on the final total TV. How you go about slicing them up
class-wise depends on how you plan to go about calculating the TV (or
vice versa), I suspect.

-- 
Jake

Re: Re[4]: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 22:24:23 +0000, Jake Staines <ja...@bi...> wrote:
> Well, you seem to suggest more or less exactly the same thing, only at
> a 'vehicle' level instead of a 'part' level; that there should be a
> 'GetTV' method at the topmost node that calculates its own TV then
> calls 'GetTV' on each of its component vehicles or sections. Same
> idea, we're just proposing using the same ultimate base class for
> systems as well at the very least. I'd be tempted to call the
> 'collection of perks' part a Part, as well, for instance, since
> essentially IIRC it just counts how many items it has (with a couple
> of special cases, true) and returns that as a single value.

True, but I think breaking things down that way at the level of
individual sections hurts more than it helps. Individual sections have
a very definite and regular structure, one that we can take advantage
of to make our lives easier by avoiding unnecessary levels of
containment. (Which we then have to manage in code) Once you get into
aggregations of sections, you unavoidably introduce complexity.

Though right now, few designs really take advantage of it, because
it's a pain to deal with. Perhaps, considering the horrors we might
unleash if vehicle designers can use transforming combining
multi-section vehicles at whim, this project is a bad idea. ;)

> Well, they kind of have something in common, in that they all have an
> impact on the final total TV. How you go about slicing them up
> class-wise depends on how you plan to go about calculating the TV (or
> vice versa), I suspect.

Very true. I just want to do so using the simplest possible method.

-- 
-Nick Pilon

Re: Parts

[Thorsten H. <gea...@th...>]

Hi,

* Nick Pilon wrote (2004-11-12 23:13):
>On Fri, 12 Nov 2004 22:57:07 +0100, Thorsten Haude
><gea...@th...> wrote:
>> >Right, but there's no greater or lesser coupling from using Parts. The
>> >interface, saving, printing, etc. still needs to know how to get the
>> >Armor. It still needs to know how to get a list of Perks, etc.
>> I don't see how they would need more than the top Part. Let's take
>> your first example, saving:
>
>The issue I see there is that it looks like Parts need to know about
>how they get written in order to write themselves.

I mixed up two things: The XML output is just another view from a
design viewpoint, but since it is an essential part of Part I think it
should go in there.

So, to keep the design clean, you would ask the Part for its
WriterView and ask this for to write.


>You're going to be writing things quite differently for a graphical
>record sheet, an HTML page, an XML save-file, and a DP9 vehicle
>block.

That's why you'd want to have different views.


>Better, I think, to provide methods for navigating whatever hierarchy
>we have set up, and then have external output writer classes that
>know how to navigate it and find what they need.

I still don't see how you could do that without *massive* coupling.


Thorsten
--=20
Wasn't the storming of the Bastille an act of terrorism?
Probably. Now it's a holiday.
    - umarsyed

Re: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 23:27:17 +0100, Thorsten Haude
<gea...@th...> wrote:
> I mixed up two things: The XML output is just another view from a
> design viewpoint, but since it is an essential part of Part I think it
> should go in there.
> 
> So, to keep the design clean, you would ask the Part for its
> WriterView and ask this for to write.
> 
> 
> >You're going to be writing things quite differently for a graphical
> >record sheet, an HTML page, an XML save-file, and a DP9 vehicle
> >block.
> That's why you'd want to have different views.

Right, which either have to somehow know their way around the part -
either the class itself or some intermediate form produced from it -
or have to be an integral part of the part. The first is what I'm
suggesting, the second is really bad style. Because to add new output
types, you have to included it in your data model classes. Kind of
trashes the whole concept of MVC, doesn't it?

> >Better, I think, to provide methods for navigating whatever hierarchy
> >we have set up, and then have external output writer classes that
> >know how to navigate it and find what they need.
> I still don't see how you could do that without *massive* coupling.

Massive coupling is only bad when it's avoidable. In this case, it is
/unavoidable/. The code for displaying the vehicle knows exactly what
data it wants, and exactly how to display that data. It knows it needs
to get the armor value, or the standard-format list of perks, and
whether it gets it from an XML file or from the class itself, you
still have the same amount of coupling. This is because our data has a
very well-defined form and structure, that anything that uses it must
know and understand in some way or another.

-- 
-Nick Pilon

Re: Re[2]: Parts

[Adam T. <kr...@co...>]

On Nov 12, 2004, at 1:58 PM, Nick Pilon wrote:

> On Fri, 12 Nov 2004 21:47:15 +0000, Jake Staines <ja...@bi...> 
> wrote:
>> Oh are they? From what I remember, a common-sense, 'normal'
>> interpretation of the contstruction rules in SilCore suggests that
>> they are /mostly/ fairly shallow, but that a OO programmer's reading
>> of the same rules would have them as anything but. Could you, for
>> instance, build a combined vehicle for which one of the parts is a
>> multi-section vehicle for which one of the locations is transforming?
>> You mentioned yourself earlier the idea of a multi-section with a
>> transforming motive section, if you're going to open that can of worms
>> then the vehicle tree is as deep as the user wants it to be.
>
> Yes, but read my other message - I address every single one of these
> concerns there. We do NOT handle this within individual sections, nor
> should we do so. We handle this by aggregation of sections.
>
> Also, vehicle perks/flaws, vehicle movement types, vehicle systems,
> and system perk/flaws have next to nothing in common. Why should they
> be forced to use a common interface for the sake of making our design
> look nicer?

Nobody says they have to use a common interface, but in order to do 
some things, they do need to speak the language of 'what is your TV?' 
and a few other things. I am used to object oriented thinking, so I 
look to see 'how do these relate to each other, and what is common to 
everything, and where do they diverge?' I wind up writing a lot of 
classes about 100-200 lines long (my 3D engine for example), but very 
little code gets reused. When I put that proposed class structure up, I 
was approaching the problem from a standpoint of: "What structure would 
allow me to have minimal coupling to each individual class, while 
attempting to keep the structure as simple as possible so we avoid 
needless extra classes and pieces". That and I am kinda used to how 
Apple approached UI design: dozens of classes, near zero code waste.

And to get back into another topic I missed, talking about 
serialization and the like:
One thing Apple did when they realized that you would have to format a 
serialization into many different forms, is to create formatter 
classes. These classes would be able to take data in a particular 
representation (string usually), and format them in particular ways 
(such as a date formatter that would layout a date string the way you 
wanted to). This concept could possibly be applied here in a similar 
manner to generate the UI, save files, HTML sheets, etc. Just attach a 
formatter onto the end of the serialization. This isn't the only way, 
but it is pretty clean and reduces high coupling if used correctly.

And why I mentioned a DTD (awhile back earlier today someone asked why 
DTD over schema), is that I know how to write a short DTD while I am 
not familiar with schema. Heck, I know how to write a XSLT to take my 
XML card data for a card game prototype and make printable HTML card 
sheets, but I don't know how to make an XML schema yet. ;)

- Adam

Re: Re[2]: Parts

[Nick P. <np...@gm...>]

On Fri, 12 Nov 2004 18:00:55 -0800, Adam Thayer <kr...@co...> wrote:
> Nobody says they have to use a common interface, but in order to do
> some things, they do need to speak the language of 'what is your TV?'
> and a few other things. I am used to object oriented thinking, so I
> look to see 'how do these relate to each other, and what is common to
> everything, and where do they diverge?'

You're not the only one.

And in this case, there is no common language. Vehicle Perks have no
TV. Weapon perks DEFINITELY have no TV. Weapon systems and movement
types do, but I'm not sure there's any meaningful overlap, as they're
dealt with very differently.

You're right that the key to object oriented thinking is finding how
things relate, and in this case, there's more divergance than
commonality. Really, the only thing at all that they have in common is
that you have to display lists of them, and even there, I can't think
of much in common.

-- 
-Nick Pilon