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

_______________________________________________
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list

Reply via email to