Re: repeating groups
Date: 19 Feb 2006 09:52:26 -0800
David Cressey wrote:
> "mAsterdam" <mAsterdam_at_vrijdag.org> wrote in message
> > Marshall Spight wrote:
> > > ... Lists are essential; sets are
> > > essential; I am not willing to admire a language that doesn't make
> > > both of them first class. I am not convinced there is any other
> > > structure that we need to give such importance to. And lists and
> > > sets need to interoperate. Hence we have to have the unified
> > > algebra.
> > >
> > > I've been thinking about this problem for a while. A half-assed
> > > job is remarkably easy. What is remarkably hard is to actually
> > > do a good job.
> > Suggested steps:
> > 0. (preliminary): device a unified notation, specifically for
> > this purpose
> > 1. Formulate the Spight list algebra :-)
> > 2. Reformulate the relational algebra
> > 3. Merge
> > 4. Pizza!
> Excellent! Maybe at that time someone will finally tell me whether a pizza
> with onions and mushrooms is or is not the same as a pizza with mushrooms
> and onions. I recall asking something like this about two years ago, in
> here, and not getting a firm answer.
Taking the question seriously...they are not the same. For people who wish to remove all mushrooms, they are easier to remove if the mushrooms are placed on last. On the other hand, if someone requests the two toppings, the order they list them has no bearing on the order they are added. The pizza chef almost always determines the ordering.
So, in the "real word" they are not the same, but if designing a pizza shop application I would not add any requirement to capture the ordering as indicated by a customer except potentially as a special order comment attribute of freeform text. I would have it display for output, and also likely for input forms, the standard ordering used by the pizza place. So, if you order a pizza with onions and mushrooms, you get the exact same pizza as if you order with mushrooms and onions. A view of that order will always have the order used by the chef.
> What I really meant by that somewhat whimsical question is whether lists and
> sets have to be implemented and described separately, or not. I'm glad to
> see the discussion coming around.
Given that there are already implementations operational, we don't have to guess at this. Implementing nested sets, bags, and lists all as nested lists is very usable and that is what I would recommend as a good starting point. Cheers! --dawn Received on Sun Feb 19 2006 - 18:52:26 CET