Re: [Ongui-dev] Thoughts on programming idioms

[Mike D. <mi...@cs...>]

Hi Robin.

> Please send documentation to the list of what problems you encounter and how
> you overcome them.

Well, so far my problem has been "I can't get any text to display."
Yesterday, I managed to get really really small text to display. If I
can't get this to work in a few more hours, I'll post my code to the
list. I sometimes have a hard time admitting defeat.

> Let's not do the m_ notation, or any other naming method Hungarianisms.

No problem. This is an affectation left over from my day job.

> If you don't mind, data members in class definitions before methods. I want
> to know what something is before I bother figuring out what it does.

It's interesting to me how different people think and approach reading
code. I prefer to know "What can I do with it", which is usually what
people walking up to an API will want to know. Especially if data
members are private (they WILL be private, won't they?). In that
sense, I was targetting our potential customers. If you prefer data
members listed first, though, I won't complain.

> Regarding method names, can you make those upper and lower rather than lower
> and upper? Your style is a bit too Java-ish for us old C++ dogs.

Heh. I don't even know Java. I'll take your word for it. :)

> > int main (int a_argc, char* a_argv[])
> > {
> > class Button1 : public OnGui::Button
>
> The definition of class Button1 had better be before main!

Actually, this was intentional. The C++ standard allows for "local"
classes, which is what I was intending to do here. This class is only
a one-off that we're only using locally for button-label binding. In
that sense, a local class is appropriate since that better represents
the true scope than a globally defined class.

However, your description of avoiding refcounting makes this a moot
point, since you prefer to shluff this sort of management (object
binding) off onto the container class (which owns both the button and
the label), which makes much more sense to me.

> > OnGui::init (a_argc, a_argv);
> > OnGui::run() ;
>
> What's this? We already have an implicit initialization and run methods.
> Don't  need these C-ish GTK-like calls.

Do you intend to pass commandline parameters to the OnGui
infrastructure? If so, how? I don't see this functionality in the gfx
archive (however, I'm not familiar with some of the Windows idioms
used there, so I may have missed it).

What's the advantage to having a member function MsgPump() for all top
level containers? Not having a Windows-centric background, this is a
little foreign to me. Why not have a global method to do this work?
How will the process handle multiple windows in a single thread? Is
each window required to run in its own thread? I'm definitely missing
something in your "big picture" here.

Also, I really dislike the use of the name of MsgPump(). It's too
hopelessly win32 to even bear. :) With your leave, I'd like to use
run() or another alternative name instead.

> Reference counting is evil.

As I said before, I now understand your take on object ownership,
etc. No refcounting needed. Understood.

> I don't know what it is you imagine counting.

However, I think I described pretty well how GTK+ forces
application developers to manage closures, which require the use of
reference counting. I wasn't _imagining_ counting anything, I just
didn't yet understand how to design applications using OnGui. Now it's
clear how things should work.

One last question, regarding your allusion to a resource file in your
sample code. How much of the content do you see being managed by the
resource file? Possibly all object attributes? Should all objects take
an optional string name as a constructor parameter?

Again, thanks for your time and patience.

-mike