Hi,
On Mon, 2010-12-06 at 01:25 +0100, Aleksander Wabik wrote:As classes not inheriting from Object have different ref and unref functions (Foo will have foo_ref, and foo_unref, Bar will have bar_ref and bar_unref), if an object is referenced by the reference of interface type, there's no possibility to ref and unref this object unless knowing what ref and unref functions to use! This may be the cause why creating references of interface type fails, and passing interface type references to functions do not fail (there's no ref then). This is a serious flaw to the object system IMO. It means, that there's *no way* of having two classes that do not have common ancestor but implement the same interface. Possible ways to solve this problem:While I also do not like that aspect of the object system, it's not really something that Vala can change. The object system is defined by GType/GObject, not by Vala. We couldn't use anything like virtual ref/unref functions as we can't expect non-Vala libraries to provide them. My recommendation is to not create too many fundamental classes. By default you should always consider using GObject as base class. If that's not an option for performance or other reasons, create a single fundamental (Mini)Object class in your application or library and use that as base for all other classes and interfaces in the same (part of the) codebase. Jürg
Abderrahim, Jürg, thank you for answers. Generally I must say, that I don't like Object at all. It too heavy, and I really miss some sort of low level programming in Vala. If I could have virtual methods in compact classes, I'd use only compact classes ;) Not being able to have virtual ref and unref is indeed an issue that is beyond Vala. It should be handled in glib. But what Vala can provide would be abstract ref/unref in the interface. I'd even say, that it could be completely handled by the code generation backend, that is, when I declare interface that does not have any class prerequisite, I don't have to create abstract ref and unref - they will be generated. And when I implement such interface in the class, I don't have to create implementations for ref and unref for the interface - the needed functions will be generated and will return pointers to appropriate functions? Would implementing such feature be possible? BTW, I'm trying to do also other 'uncommon' things in Vala - such as defining custom ref/unref for the typed, but non-Object class. I'll describe my observations in another mail in some time... Vala is excellent GObject language, but it has various shortcommings when one tries to use it for a little bit lower-level programming. I believe that most of these shortcommings can be solved, and if I have some time, maybe I'll even hack on Vala a little bit ;) I know that resources are limited, and there certainly are higher priority tasks, but if I need something and I'm willing to implement it myself and share...? But to whom should I write with, how to say, feature requests? To Jürg? best regards, AW. -- Mój klucz publiczny o identyfikatorze 1024D/E12C5A4C znajduje się na serwerze hkp://keys.gnupg.net My public key with signature 1024D/E12C5A4C is on the server hkp://keys.gnupg.net
Attachment:
signature.asc
Description: PGP signature