Re: [Gnue-dev] Why the Object metaphor? (Was: Object-Relational Mapping?)

[Jason Cater]

Neil, 

My email wasn't targeted at you. I did quote you once as it tied into a
lot of what I was reading other people saying. But it wasn't targeted at
you. It was a generic email. And I was not ticked -- I am being devil's
advocate by asking the question "why?"

I am also not being arrogent to say one model is better than another.  The
whole point of that last email was to make people question the assumptions
they are making about their object view of the world. They say it is more
intuitive for the end user. I ask WHY? All I get is the implication that I
am misunderstanding the point and that I am talking at a lower logic
level.  I turn around and say, well my point is being misunderstood too
and that I'm talking about the abstraction layer presented to the user to
customize. 

I guess I am confused.  At one minute we are talking about how the end
user will be presented with the business logic and functions so that he
can expand it ("modifying system behavior") to fit his business needs. The
next we are talking at some "conceptual" level and that I am just being
overly reactive to specific terminology. I am trying to discuss the
former. 

Unfortunately, I have not seen any concrete examples of the former, but
hear that treating them as business objects will be more intuitive. All I
ask is WHY it is more intuitive. What other options are there? I am not
saying I have that answer, but was giving examples of how the
end-user/customizing person can just as well understand a spreadsheet-like
metaphor. Maybe it's not best, but WHY or WHY NOT? I certainly think the
object metaphor will quickly fail outside of the most mundane
customizations, but of course I've made no secret of that. 

Also, all I have to go on are the abstraction models I am seeing evolve in
the App Server layer. My understanding is that will be the abstraction
layer that will be presented to the user to customize. And that is an
object model, with all its inherent problems I am trying to raise. Maybe
there is another layer on top of that I am missing. If so, I apologize. 
If not, I don't care if you call it a business object, or whatever. My
question remains:  how does the user get anything accomplished? 

I understand the point you are getting across with the business rules;
i.e., it is easy to add logic to a Purchase Order; e.g., POs cannot be
issued on a Sunday as the office is closed on a Sunday. (Maybe that's not
a realistic example, but I think it will work here.)  It is really easy to
add that to a "Purchase Order" business object. The model works well for
this case. 

But what about after that? How does the user actually use the system
afterwards. Business rules are only one part of the equation -- a part
that objects work well with.  Business reporting, in my opinion, is
another equally important part of the equation. Having custom business
rules without easily being able to report against custom "enhancements"
will be fairly useless. Will any custom reporting be left to an
"application developer" as Dan says? If so, what's the point of only being
able to modify business rules? The user can implement rules but not
generate custom reports? That doesn't seem like a very extensible system
to me. 

My wife has a used bookstore where books cost half the original cover
price. She adds a "cover price" property to her inventory business object
and adds a rule that [ price = cover price * .50] How does she make use of
these customizations outside of the extra rule placed on integrity? 

> It would have helped a lot more if you would have explained what 
> direction you see the abstraction going and how it will be presented 
> to the user since that was the point to my emails.

I am trying to get people to justify their stance.  I gave some conceptual
examples of tasks the end user may try to do themselves, and how I thought
the terminology fails.  I am told I am thinking too low-level.  At what
point is the line crossed?  Once the user gets out of defining business
rules and into getting useful information out of the system? Or is it
lower than that? Higher than that?

> If that is not the direction of GNUe, please let 
> me know and I will shut up.

One of the first lessons I learned when starting with GNUe is that the
client tool developers are not taken seriously when the subject of
business rules programming comes up. Just for the record, this isn't some
academic exercise for me either. I don't want to end up with yet another
heap of useless code on my hands that is worthless to my companies. 

For the sake of completeness, let me once more clarify: I am not trying to
advocate one model over another... I am wanting people to ask themselves
why they are making the assumptions they are. This will be my last email
on the subject as I have failed in this goal. I've only seem to get
reactions, not explanations :( 

But I am not ticked off.

-- Jason