At my day job, we're currently are having an intense discussion over a
data structure with the following abstracted format:
; '(baz-A (baz-B (baz-C (foo 35))
; (foo 66)
; other-stuff)
; (foo 27)
; (baz-B (foo 11)
; (foo 13))
; other-stuff)
So basically, the data is hierarchically structured based on different
"baz" tags, but, additionally, infused into the data are a bunch of
"foo" data elements and a bunch of other stuff- Of course, in our
real-life case, this structure would have many more levels and
thousands of individual nodes.
This data structure is very dynamic and needs to be continuously
updated and new tags deleted and added at all levels, more often than
not the "foo" data elements.
Since my co-workers are highly experienced Pattern OOP designers, they
naturally want to break this data structure into nested objects (such
as class_a class_b class_c) and then create member functions such as
class_a.add_foo(...), class_a.get_b(...) class_b.add_foo(...). The
resultant object structure would be defined basically as follows:
struct class_a{
List<class_b>child_bs;
List<integer>child_foos;
...
};
struct class_b{
List<class_c>child_cs;
List<integer>child_foos;
...
};
struct class_C{...
etc.
So when I saw this design I basically said this was going to be an
incredibly cumbersome way to do it, because for each of these classes
there could be no "foos", many "foos", or one "foo" or you have to
query the child objects and look at their "foos"- Any part of our
program that needs to work with foos is going to have to do ridiculous
amounts of bookkeeping to hunt down and modify foos.
Basically, since there is not a one-to-one relationship between the
"foos" and any of the defined classes, "aliasing" the data based on
these objects is inappropriate from a design standpoint. (Note that I
am using a different meaning of "object aliasing" than how the term is
commonly used)
Instead, I am suggesting we use a data structure that is a more
suitable "heterogenous" hierarchical non-OOP data structure, such as
sexps or xml. In that case, any code that needs to get, create or
modify "foos" can ignore non-foo-related tags, which is clearly far
easier in this case, I think.
Unfortunately, my coworkers are arguing that I have taken their data
structure and just created an sexp version of it. They are arguing that
the nested objects and the sexp are just "the same thing" and that we
should stick to standard OOP methodology in this case.
I think they are clearly not the same thing, as I'm sure the folks who
understand the benefits of ordered heterogeneous tree-based data
structures can immediately appreciate. What I'm wondering is if there
are any technical resources or web pages I can point my coworkers at
that discuss this type of "object aliasing" and how it causes
significant complexity if a composite OOP design is used.
Apologies for the horribly long post :)
-Conrad Barski, M.D.
www.lisperati.com
······@gmail.com wrote:
> Unfortunately, my coworkers are arguing that I have taken their data
> structure and just created an sexp version of it. They are arguing
that
> the nested objects and the sexp are just "the same thing" and that we
> should stick to standard OOP methodology in this case.
>
> I think they are clearly not the same thing, as I'm sure the folks
who
> understand the benefits of ordered heterogeneous tree-based data
> structures can immediately appreciate.
That's right; they are not the same thing. S-expressions are the
printed representation of the data, and the objects are the internal
representation!
Even if you use S-exps for the external representation, that doesn't
mean you have to use the corresponding list structure internally. Lisp
programs don't always do that. Sometimes what appears to be a list in
the data file becomes a structure, or a CLOS instance.
Are you folks arguing about how to store the data in files, or about
how to manipulate it it memory, or both?
What I'm wondering is if there
> are any technical resources or web pages I can point my coworkers at
> that discuss this type of "object aliasing" and how it causes
> significant complexity if a composite OOP design is used.
Regardless of that, S-expressions are still a good way to flatten
objects for transmission and storage.
······@gmail.com writes:
> [...]
> Instead, I am suggesting we use a data structure that is a more
> suitable "heterogenous" hierarchical non-OOP data structure, such as
> sexps or xml. In that case, any code that needs to get, create or
> modify "foos" can ignore non-foo-related tags, which is clearly far
> easier in this case, I think.
>
> Unfortunately, my coworkers are arguing that I have taken their data
> structure and just created an sexp version of it. They are arguing that
> the nested objects and the sexp are just "the same thing" and that we
> should stick to standard OOP methodology in this case.
>
> I think they are clearly not the same thing, as I'm sure the folks who
> understand the benefits of ordered heterogeneous tree-based data
> structures can immediately appreciate. What I'm wondering is if there
> are any technical resources or web pages I can point my coworkers at
> that discuss this type of "object aliasing" and how it causes
> significant complexity if a composite OOP design is used.
So, it seems your coworkers are specializing too much.
Indeed, when it's easy to generalize all these specific classes and
implement generic methods that can process in a uniform way all the
specific cases, it's much better to only implement one this generic
class rather than special cases. (By the way, if they were thinking
in a language that has macros, all these special cases would be
implemented from one macro).
But it's so obvious that it's much better to write one generic class
rather than N specific classes, I can't believe your "coworkers" are
for real.
CONS is the ultimate generic class!
--
__Pascal Bourguignon__ http://www.informatimago.com/
This is a signature virus. Add me to your signature and help me to live
> So, it seems your coworkers are specializing too much.
Well, I may have oversimplified the issue a little bit in my question.
The problem is that the baz-A, baz-B, baz-C tags require their own
specialized code, but also have generic behavior in terms of their
common ability to contain 1 to n foo items- Basically, it's like there
is a tree of data which can be specialized in two orthogonal ways-
Either based on the type of "baz" tags, or on their ability to have
"foos". My argument is that since there are two competing ways of
breaking the tree of data into objects, it makes more sense not to
break it up at all, but to maintain it internally as a generic sexp -
Any function that needs to parse this data can then choose, on its own,
whether to traverse it as nested "baz" items or as nested "foo"
containers.
I think, unfortunately, that my particular circumstance may be too
specific to be able to find a good reference to point to that relates
to it- It's hard enough to explain it properly as it is.
However, thanks Kaz and Pascal for giving me additional angles to think
about my design problem with!
-Conrad
The key to your example is "other_stuff", which means "stuff of a type
I may not know yet, except it behaves like a tree".
Therefore, you need one class that represents a tree node with a list
of child pointers, and a bunch of operations on such nodes. Individual
nodes may then actually be subclasses, and contain other, non-tree
data. A tree node then stores a tag (enum, for example) identifying its
true type. You can then have very useful functions, such as
RecursiveTraverse(Node*, Tag type, callback), where callback will be
called in turn for each node of specified type.
So it's quite manageable, you just have to shove all the beautiful OOP
stuff aside in favor of usability.
In article <························@z14g2000cwz.googlegroups.com>, ······@gmail.com wrote:
> At my day job, we're currently are having an intense discussion over a
> data structure with the following abstracted format:
>
> ; '(baz-A (baz-B (baz-C (foo 35))
> ; (foo 66)
> ; other-stuff)
> ; (foo 27)
> ; (baz-B (foo 11)
> ; (foo 13))
> ; other-stuff)
>
> So basically, the data is hierarchically structured based on different
> "baz" tags, but, additionally, infused into the data are a bunch of
> "foo" data elements and a bunch of other stuff- Of course, in our
> real-life case, this structure would have many more levels and
> thousands of individual nodes.
>
Hi Conrad,
What you are describing sounds like a structure that I've seen a lot in
the last five or six years.
If you will allow me to rephrase this problem in a way that I've been
having to deal with, your example becomes (assuming no typos nor crossed eyes):
<baz-A>
<baz-B>
<baz-C>
<foo>35</foo>
</baz-C>
<foo>66</foo>
<other-stuff/>
</baz-B>
<foo>27</foo>
<baz-B>
<foo>11</foo>
<foo>13</foo>
</baz-B>
<other-stuff/>
</baz-A>
This example is so simple that it can be misleading. In the kind of thing
that I've been doing there would be a bunch of attributes on each xml
element (all optional) and the contained elements would have unconstrained
count, there would be *many* of these structures, and they would be much
bigger. Furthermore, the application program would be very interested
in which node appears where and what values the attributes would have
(those are not just cons cells in there).
In my experience, objects are good things to have to play with
in the application and really bad things to have outside of the
application. Until recently everything I've been doing has been in Java,
so XML seemed like a good external representation, and it is. Now I'm
doing lisp stuff and there is an alternative to XML that is almost as good
which is the sxml (I think it is called) representation (it allows for
node attributes but otherwise is an sexp). I think XML has some advantages
-- in particular XML represents a document where sexps do not, quite;
and very importantly, it helps to hide the fact that I'm using lisp :-)
The trouble is that using objects involves a *huge* amount of drudge work.
I've got a couple of tools that can help. The Java tool is very advanced
and probably not very interesting to you or anybody else in this news
group, except maybe in passing. The Common Lisp tool is very new, and
very small compared to the Java tool (both are very easy to use). I
expect that the lisp version will move to the same place that the Java
tool now occupies, but that will take a while. Anyway, the lisp tool can
convert a given XML document to a CLOS structure and provides a bunch
of convenience methods. In particular it:
* generates, in my opinion, pleasant-to-use CLOS classes that reflect
the XML,
* reads and writes the CLOS structure from/to XML,
* maintains document order,
* allows text content (XML mixed content as well as simple elements),
* allows for indexing of child nodes by an attribute value,
* provides methods to add, remove, replace, find child nodes and few
other things
* handles XML namespaces
* and some other stuff that isn't important until you need it
I'm using it to develop a product for my company and am adding
functionality that is necessary for that task as I go (this tool has
been evolving for the last 5-6 years, it wasn't planned out -- the first
useful thing it did was pretty print XML :-) Currently, for my project,
it is generating 96 CLOS classes and about 700 interesting methods (your
baz example above generates 10 classes, I don't know how many methods,
probably about 75)
The Java version has been used in the last two years to build, among other
things, four complete loan management systems, a trading partner system,
a web presentation tool, and a community of practice system. None of
these are what most people would call 'small applications', nor 'simple
applications'.
I'm planning on open sourcing the lisp version of the tool, but it isn't
ready yet in my opinion. And, at the moment, it only works in LispWorks
(because it uses unicode internally). If this kind of thing would be
interesting let me know, I can probably speed up the process.
I don't know if this is the kind of thing you wanted in response to your
question, never-the-less I hope it helps.
Cheers,
Bob
www.recursive.ca
hutch <·····@hutch.local> writes:
> I'm planning on open sourcing the lisp version of the tool, but it isn't
> ready yet in my opinion. And, at the moment, it only works in LispWorks
> (because it uses unicode internally). If this kind of thing would be
> interesting let me know, I can probably speed up the process.
clisp, and now sbcl have unicode too.
--
__Pascal Bourguignon__ http://www.informatimago.com/
Nobody can fix the economy. Nobody can be trusted with their finger
on the button. Nobody's perfect. VOTE FOR NOBODY.