Prev: Abstraction & singleton
Next: event handling issues in presentation model
From: S Perryman on 1 Feb 2008 10:24
topmind wrote:

> S Perryman wrote:

>>You have certainly shown that your solution *cannot deal* with #2 and #3.
>>Your "table" combinatorially explodes as the cartesian product of
>>types and properties. Every type represented in that table, and the
>>functions associated with the type, are impacted by *every change* to the
>>table.

> Please clarify. I don't see a combinatorial explosion. What
> "function" are you referring to?

I am going to nail this one for good.

The topic : variant records
The example : publications records systems (libraries etc)
The example source :

Object Oriented Software Construction (2nd ed) , pages 61-62.


In order to simplify the debate (source code etc) , I have limited the
scope to the creation of publication entities, and read access to their
properties.

I have provided a simple impl using type substitutability. All of the
features and mechanisms used are supported by *real* (not fictional) prog
langs/envs.


Provide your *like-for-like* implementation in "procedural/relational" form
for the above. Indicate where appropriate where the artifacts (interfaces
etc) are in the same or different modules (source files etc) .

You are not constrained to any particular prog lang/env. You can take the
mechanisms etc from wherever you so desire. But said mechanisms must be
demonstrable in *existing* prog langs/envs (fantasy has no place here) .

If you can fit your impl within a reasonably-sized Usenet posting, do so.
If not, put it somewhere (web page etc) where we can see it.


Once we have your impl, we can start to discuss the real issues of the
variant record problem that you claim "procedural/relational" does not
introduce/suffer
(see http://groups.google.com/group/comp.object/msg/745997a1bc30949f) ...


Regards,
Steven Perryman
From: topmind on 1 Feb 2008 11:37


S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> >>You have certainly shown that your solution *cannot deal* with #2 and #3.
> >>Your "table" combinatorially explodes as the cartesian product of
> >>types and properties. Every type represented in that table, and the
> >>functions associated with the type, are impacted by *every change* to the
> >>table.
>
> > Please clarify. I don't see a combinatorial explosion. What
> > "function" are you referring to?
>
> I am going to nail this one for good.
>
> The topic : variant records
> The example : publications records systems (libraries etc)
> The example source :
>
> Object Oriented Software Construction (2nd ed) , pages 61-62.
>
>
> In order to simplify the debate (source code etc) , I have limited the
> scope to the creation of publication entities, and read access to their
> properties.
>
> I have provided a simple impl using type substitutability. All of the
> features and mechanisms used are supported by *real* (not fictional) prog
> langs/envs.
>
>
> Provide your *like-for-like* implementation in "procedural/relational" form
> for the above. Indicate where appropriate where the artifacts (interfaces
> etc) are in the same or different modules (source files etc) .
>
> You are not constrained to any particular prog lang/env. You can take the
> mechanisms etc from wherever you so desire. But said mechanisms must be
> demonstrable in *existing* prog langs/envs (fantasy has no place here) .
>
> If you can fit your impl within a reasonably-sized Usenet posting, do so.
> If not, put it somewhere (web page etc) where we can see it.
>
>
> Once we have your impl, we can start to discuss the real issues of the
> variant record problem that you claim "procedural/relational" does not
> introduce/suffer
> (see http://groups.google.com/group/comp.object/msg/745997a1bc30949f) ...

Before I do so, I need to know what success criteria I am trying to
optimize here. I can think of a least 3 different ways to go about
this.

For example, if data integrity is the single utmost concern, I might
make a separate table for each publication "type".

However, if having user-creatable/alterable publication "types" is
also important (or at least table-driven pub type creation to avoid
touching app code), I wouldn't make separate tables for each "type",
but have a shared table instead.

We can also go full-out dynamic and allow a "power user" to add as
many fields as they please and as many "publication types" as they
please.

I don't want to get all the way through only to have you say, "I don't
care about those other factors, mine objectively does better on factor
X, and thus you've been beaten." I generally strive for the best
compromise of lots of factors (code volume, servicability, external
tool exportability, reliability, cost, etc.). If you are going to
drum on a single factor, which often happens in these kinds of
debates, then we will just end up talking past each other.

Targeting a single-shot implementation and targeting a tool that many
or any library can use will also change the nature of the app. If you
target many organizations, one usually finds that different places
have different ways of doing things, even if it is not the most
logical, and the sales team wants you to accommodate their
idiosyncrasies as best you can.

Further, the issue of how do deal with multi-media publications, such
as a book that comes with a CD and/or a VCR tape, has not really been
addressed. (It may depend on how the library wants to track them: as
a single publication or separate ones.)

Thus, we need to be clear on these up front.

>
>
> Regards,
> Steven Perryman

-T-
From: S Perryman on 1 Feb 2008 12:06
topmind wrote:

> Before I do so, I need to know what success criteria I am trying to
> optimize here. I can think of a least 3 different ways to go about
> this.

There are no "success" criteria, beyond providing something to compare.
That aside :

1. The issues concerning the variant problem relate to change, and
correctness (as I stated way back when) . Performance issues (size, speed)
are therefore not a consideration (for me anyway) .

2. We are not building a publications meta-system (user-definable
publication types etc) .


[ snip ... ]


Regards,
Steven Perryman
From: topmind on 1 Feb 2008 12:53
On Jan 31, 9:06 am, S Perryman <q...(a)q.com> wrote:
> topmind wrote:
> > Before I do so, I need to know what success criteria I am trying to
> > optimize here. I can think of a least 3 different ways to go about
> > this.
>
> There are no "success" criteria, beyond providing something to compare.
> That aside :
>
> 1. The issues concerning the variant problem relate to change, and
> correctness (as I stated way back when) . Performance issues (size, speed)
> are therefore not a consideration (for me anyway) .
>
> 2. We are not building a publications meta-system (user-definable
> publication types etc) .

But above you said "change". Meta-tizing stuff often makes it easier
to change. If I use a feature table, I can add or change many
publication fields/features or "types" withOUT touching a *single*
line of code. Thus, if your change metrics is "how much code is
changed", you are gonna get hammered on that. If you want to get
slammed on that criteria, that's fine by me, but I want to make sure
this is known up front so that I don't waste code on a known sore
point.

And I don't think it is fair to count a meta-table change as "severe"
as an app-code change. Why should adding a new specific publication
instance be counted low but adding a new publication "type" be counted
high? That does not make sense to me.

I would probably count a meta-table change as more costly/risky than
adding a new book instance (regular data entry), but not nearly as
much as having to change the app code. It is somewhere in-between.

It seems more and more that the outcome of this will depend on how one
scores both the frequency and costs of various change scenarios.

What I find in similar debates is that OO'ers often have poor sense of
change frequency and cost (at least compared to my observations/
experience). They overweigh specific changes at the expense of more
realistic changes. I think OO books hammer on a few change patterns
over and over and eventually it brainwashes the reader to only see OO-
friendly changes. It's like TV commercials that point out say split
ends: stuff one would probably hardly notice if the commercial didn't
make it sound like The Express Train to Uglyville.

OO authors have psyched-out the IT world.

>
> [ snip ... ]
>
> Regards,
> Steven Perryman

-T-
From: S Perryman on 1 Feb 2008 13:01
topmind wrote:

> On Jan 31, 9:06 am, S Perryman <q...(a)q.com> wrote:

>>topmind wrote:

>>>Before I do so, I need to know what success criteria I am trying to
>>>optimize here. I can think of a least 3 different ways to go about
>>>this.

>>There are no "success" criteria, beyond providing something to compare.
>>That aside :

>>1. The issues concerning the variant problem relate to change, and
>>correctness (as I stated way back when) . Performance issues (size, speed)
>>are therefore not a consideration (for me anyway) .

>>2. We are not building a publications meta-system (user-definable
>>publication types etc) .

> But above you said "change".

Correct.


> Meta-tizing stuff often makes it easier
> to change. If I use a feature table, I can add or change many
> publication fields/features or "types" withOUT touching a *single*
> line of code. Thus, if your change metrics is "how much code is
> changed", you are gonna get hammered on that. If you want to get
> slammed on that criteria, that's fine by me, but I want to make sure
> this is known up front so that I don't waste code on a known sore
> point.

We shall see, shall we not.


> And I don't think it is fair to count a meta-table change as "severe"
> as an app-code change. Why should adding a new specific publication
> instance be counted low but adding a new publication "type" be counted
> high? That does not make sense to me.

If you wish to use "meta-tables" as a *developer* , that is fine.
But we are not implementing a publications meta-system where the end
user can define their own publication types.

Other than that, keep to the example as I defined it ...


Regards,
Steven Perryman
 |  Next  |  Last
Pages: 1 2
Prev: Abstraction & singleton
Next: event handling issues in presentation model