Re: Whose Fish?

This thread is about the Whose Fish riddle, and you're going off on
your typical BS. As usual, because it's the only thing you have to
say. I don't care to argue the same points you've been arguing on
every other thread on this NG. And now this thread looks just like
any other, regardless of its potential.

If your justification for the example looks like any other reply then
of course my answer will also. It is not my fault that all roads lead
to Rome.

Rome may be connected to the road system, but that doesn't mean you
have to keep going there.

Ugh, Whose Fish would have been so much more interesting than business
apps, which you are stuck on.

Perhaps. But practicality should trump mental masturbation unless we
are entering "American Paradigm Idol".

Why is "mental masturbation"? Because it wasn't a paying project?
Neither was your customer / invoice program. You wrote that
completely for completely intellectual / educational purposes too.
Same as what I did. You just don't don't like the Whose Fish puzzle
because it's harder, so you're trying to degrade it by writing it off
as something below you.

Have a good look at Lhotka's CSLA reusable business framework.

Awk! He's selling a book. At least the Payroll example is free. He
also mentioned "distributed environment". This usually means a RDBMS
hater, so my yellow flag is up. I already spent gobs on OO books
recommended by others.

Lhotka's very robust reusable business framework is available for
free, and it's completely documented in code. There are also example
projects demonstrating how to use it. You don't have to buy the
book.

And there is nothing RDBMS hater about it. It works very much hand in
hand with the RDB.

Once again, I throw something out and you dismiss it immediately.
Let's face it: OO can (and does) write the same apps with the same
functionality (CRUD, business database apps, etc), AND it can handle
all the stuff that PR doesn't do well at (drivers, CAD, frameworks,
etc). You don't prefer it.. I do.

And I don't buy your implications that "OO" means loading the entire
contents of the database into an in memory OO DB of composition and
hierarchies. Most database are size prohibitive for that anyway.


Yes, the author obviously models their own view of the world. So?
And some models will function better than others.

Beyond "correct output", "better" is probably also in the eye of the
beholder. My wife's method of organizing (wooden) desk doodads is
different than mine. Is one or the other "wrong"?

Better, to me, means the assurance that a change won't indirectly
cause other bugs. That means that the code has to be organized in an
intuitive way, as it is with a good object model, and the logic is
encapsulated inside those models in an intuitive place. Then it is
easy to see what will be affected by changes.

You have your mind made up already.

It is not. If you show me OOP kicking P/R's bootie in a clear
objective way, and I'll reconsider.

You just said that better is in the eye of the beholder, and you
already behold your way as better.

Now, if this was actually a forum of OO enthusiasts, I can see posting
the code of this puzzle for everyone to enjoy. However, in the
current context, I don't think it is.

In practice they are indeed middle ground. However, OO has become kind
of elistist, and is comparable to "eat your vegitibles". People are
made to feel guilty if they are not doing OO.

I hate elitism but I like OO. The industry has been so dataset
oriented lately that I feel more persecuted as an OO fan than not.

Most programming language frameworks are OO, so it behooves most
programmers to be grounded in OO programming concepts.

The projects that do incorporate OO still use a relational DB as
opposed to loading the entire DB into objects.

They still do a lot of DB mirroring. In-App composition & aggregation,
common OO techniques, is a form of mirroring. One generally does not
do this in P/R because one uses queries to "flatten" the view to fit
the particular task at hand.

Whatever, most of the apps that I've ever worked on only load the data
that is necessary for the current use case. So the data is still
flattened, but it's in objects instead of table structures. At that
point, why does it matter if they are composed? The composition
collection is already flattened.. it just needs databound into a
control most of the time anyway. There is no need to traverse
anything.

Although I will say that the next version of C# will have an
integrated query language for querying in memory collections. (yay!)

Sets and relational seem to work pretty well most of the time for biz
apps. OO thinking seems to ignore them.

No, it just skins them in objects with related behavior. And for
maintenance, I know if I change the behavior of an object, I'm not
going to inadvertently affect the behavior of other objects in the
code.


.

Relevant Pages

  • Re: Whose Fish?
    ... OO can write the same apps with the same ... My view of how I query info may be different than even what ANOTHER ... Most programming language frameworks are OO, ... In-App composition & aggregation, ...
    (comp.object)
  • Re: mfc pitfalls
    ... In most MFC apps, you are writing code in that kind ... virtual methods usually work better than callbacks for most ... no syntax in the design for function pointers. ... programming in OO environment requires new ...
    (microsoft.public.vc.mfc)
  • Re: WWW/Internet 2009: 2nd CFP until 21 September x
    ... If you can decompose the table into multiple tables each of which has no nulls, what you discover is that a null in the combined table corresponds to an absent row in one of the decomposed tables. ... If I knew then what I know now, I would have refused the whole business and gone into a sensible line of work. ... At one time, maybe it was when Dijkstra was active and 'The Psychology of Computer Programming' was a current book, this culture was evident amond C programmers. ... I have some sympathy for Walt's comments on the grounds that I thought more than half of the apps I saw wouldn't have been needed in those businesses if I had been signing the cheques, let alone most of the requirements. ...
    (comp.databases.theory)
  • Re: Whose Fish?
    ... That would be much more in line with your Table Oriented Programming ... currently programming) non CRUD business apps. ... intuitive way, as it is with a good object model, ... I might load CustomerInfo with read only ID ...
    (comp.object)