Re: [Vala] Vala object model

[Sam Liddicott <sam liddicott com>]

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 <juanluispaz gmail com>
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