On Fri, 2004-08-27 at 03:27, Ryan McDougall wrote:
> On Fri, 2004-27-08 at 02:57 +0000, Tiago Cogumbreiro wrote:
> > One thing I've learned from reading the big reference on GObject
> > documentation[1] is that howtos/quick refs/faqs and theoretical
> > explanations don't, usually, mix. While reading it I usually wanted to
>
> I disagree. Sometimes you want to know how without why, and sometimes
> you want to know why. Thats why there is all kinds of types of doc to
> look at. I always have a tutorial and reference open beside each other.
But you've just agreed with me, i explicitly say that you have a) a
tutorial and b) a reference, that strikes me as two documents for two
different things ;)
>
>
> > Maybe you could explain in the document why you chose GTypeInstance and
> > why we use GObject instead. The same thing regarding to GTypeClass
> > versus GObjectClass. Also, when G_DEFINE_TYPE_EXTENDED is introduced the
> > reader should know the differences between these types, otherwise i
> > think it's a bit confusing on why the object definition changed because
> > of one macro. Wasn't the reader supposed to know how to define a class
> > already? Why did the procedure changed?
>
> I already have the following in the doc:
>
> <notice>
> While we will reuse the ideas and patterns we have discussed above
> throughout the text, attempting to create a fundamental type that
> behaves as it should with other GTK+ code is very difficult and in-
> depth. It is recommended that you always create new types by deriving
> from GObject, since it does a lot of background work to make things
> behave how GTK+ assumes it should. From now on all our objects will
> derive from GObject, which will be the subject of our next section.
> </notice>
>
> I have introduced the macro after GObject.
>
> >
> > One more thing, introducing constructors before properties doesn't seem
> > to be the best thing to do, because constructors are only used to check
> > properties passed through the g_object_new marked with
> > G_PARAM_CONSTRUCT. Therefore i think you should just introduce the user
> > the _init method. Also why do you show _finalize and _dispose? For one
> > thing readers will usually only use _finalize, another is that you don't
> > explain the difference between them.
>
> I actually tried my best to explain the difference between them. Its all
> there in the text. Did you skip the text and go straight to the code? ;)
Most probably :D
>
> > So maybe first you could explain the _init and _finalize methods then
> > explain properties and the go back and explain the _constructor.
>
> Constructor is presented first since its a more fundamental OO concept
> than properties (which is just a nice mechanism). But in reality the two
> are intertwined. If I show properties first then people that means
> GObject is basically the LAST thing I show. Theres no perfect way to
> treat something so complicated.
IMO, properties are not less important then constructors. In most OOP
books constructors are not one of the first things to be explained
whereas properties, in it's conceptual state, are.
It is usual to have an example like this
class Car {
int doors;
}
c = new Car();
c.doors = 4;
And a 'door' is a 'Car's property. You never start explaining OOP by
explaining what a constructor is. But then again that's just my humble
opinion ;)
_______________________________________________
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
