A fact: I can't start a class from GTypeInstance in vala 0.3.5, Vala will try to use GTypeInstanceClass as the c class name whereas GTypeClass should be used.
and in glib-2.0.vapi TypeInstance is labelled as deprecated. Yu On Thu, 2008-08-07 at 14:16 +0100, Sam Liddicott wrote: > Hi Juan, > > I'm not qualified to give any official response, but as I'm working to > support more underlying class implementations I'm very interested in > what you say. > > -----Original Message----- > From: Juan Luis Paz <[EMAIL PROTECTED]> > Sent: 06 August 2008 23:16 > > ... > >In this moment vala have two kind of object, the > >object based in glib and the others tagged as > >"compact", all class are automatically based in glib > >except the classes tagged with the compact > >attribute; > > Features available in compact classes will increase, including virtual > methods. The difference between gtypeinstance classes and compact > clases will be mere implementation details, the main distinction being > that class and object overheads (type casting implementation, virtual > method table etc) wil have to be explicitly specified for compact > classes whereas gtypeinstance/gobject classes have a regularly defined > model implementation. > > >in the glib exists two fundamental base class, the > >GTypeInstance (actually named TypeInstance in > >the glib vapi file, with the comment: "deprecated") > >and GObject (actually named Object in the glib vapi > >file), the second extends the first; and all class > >without super class extends automatically from > >GTypeInstance > > > >I propose create a logical class named "any" and > >all class registered in vala extends "any" (like Eiffel > >program language), all base class for any type > >systems extends "any" and all compact class > >extends "any" (the compact class is a reduced type > >system). > > See above, compact clases need no longer be reduced. > > > "any" is the logical super super class in vala, for > >this extends all elements registered in vala: > >classes, structs, etc. > > > >With "any" class, the object model look like: > > any > | > + ----- GTypeInstance > | | > | + ---- GObject > | | > | + ---- MyGObjectClass > | > + ----- MyCompactClass > | > + ----- AnotherCompactClass > | > + ----- AnotherTypeSystem > | > + ---- MyClassWithAnoterTypeSystem > > >For more usability I propose create two aliases: > > object = GTypeInstance (actually TypeInstance) > >gobject = GObject (actually Object) > > > >object is the super class for all gobject type > >system based class, like java and C# > > > >Why object is GTypeInstance instead GObject? > > Because GTypeInstance can be handle all gobject > >type system based classes, this is the real > >superclass for all types based in gobject type > >system > > I don't quite follow the logic, it sounds like you are saying that > object should be gtypeinstance because it is the superclass of > gobject, but that seems a weak reason, but I may have misunderstood > the reason. > > However, I would agree with the suggestion anyway, as this is the > first class with proper object qualities... except that soons compact > classes will also have these qualities... > > >For prevent confusion when use gobject type > >system with another I propose rename this classes > >(from the glib vapi file): > > "Type" to "GType" > >"TypeInstance" to "GTypeInstance" > >"Object" to "GObject" > > Hmmm > > >For close the large discussed issue about the > >default base class, I propose change it for > >GObject, this is the natural base class for the news > >classes; for use another super class must be > >indicate explicitly. > > Makes sense, although assumption about gobject this might only be true > for gnome projects. > > ... > > >Now, the compiler can identify the compact class > >without the compact attribute, it is unnecessary > >and can be dropped > > Well... Maybe, only maybe; the breadth of compact classes actually > increases with attributes to specify forward casting, backwards > casting, vmt, class data, etc. These will need specifying somehow. > > My perspective is of using vala to extend existing projects, like > samba or the linux kernel that already have their own psuedo object > system. > > Further such compact classes can be subclassed indirectly by gobject > (a simple wrapping technique) although the gtype system may not be > able to learn much about the parent classes, virtual methods > implemented by the non-gtype object etc will still work. > > >About the use of "any": > > > >"any" is a metaclass, and this does not indicate > >how to handle its memory; unknown how handle > >its memory makes impossible to use "any" as type > >of argument, variable, field, etc. then, the valid > >use of "any" is in a pointer, any* is the same as > >void* > > > >Note: > >I prefer any* instead of void* because any* is >has > >a logic reason, void* is magic and illogical, but > >void* is very common > > "Any" has a is meaningful in a literal way for argument types, but not > for subclas declarations. > I prefer void as the parent class, it is literally meaningful in both > cases and not unexpected. > > >Note: > >In the variable argument list, the data type of > >"..." is any > > >Note: > > I'm not sure, but I think some methods in GObject > >class are GTypeInstance methods like get_type( ) > > > >With this change vala has a consistent object > >model, without exceptions (actually the compact > >classes are exceptions), and open de possibility to > >support another type system with the same level > >as gobject type system, only one consideration > >must be understand the vala programmer when > >use across type systems: the capabilities of each > >type system > > > >I would like to receive your opinions. > > > >PD: I apologize for my bad English, I'm Spanish-speaking > > Your english is fine! > > Sam > _______________________________________________ > Vala-list mailing list > Vala-list@gnome.org > http://mail.gnome.org/mailman/listinfo/vala-list _______________________________________________ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
