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
_______________________________________________
Vala-list mailing list
Vala-list gnome org
http://mail.gnome.org/mailman/listinfo/vala-list
