Re: [Vala] Interfaces - why do they must have prerequisites?
Hi,
no, you did not understand: I'm not trying to create object from an
interface. I'm having class Foo, that is _NOT_ inheriting Object, but
it's still a typed class, and it's implementing interface IFoo. This is
(or used to be) legal. I'm creating instances of that class, but the
reference is of interface-type:
// --- test.vala ---
namespace Test
{
public interface IFoo
{
public abstract bool run();
}
public class Foo : IFoo
{
public virtual bool run()
{
return true;
}
}
public static void main()
{
IFoo ifoo = new Foo();
ifoo.run();
return;
}
}
// - end test.vala -
In my opinion it SHOULD be legal. I don't see a point why it's not
legal now, and I don't understand the error message:
error: missing class prerequisite for interface
`Test.IFoo', add GLib.Object to interface declaration if unsure
IFoo ifoo = new Foo();
As I'd understand this message, it means that an interface MUST have a
prerequisite of a classed type. It's an absurd, why is it so? Can't I
have an interface not having any prerequisites? Manual suggests so, the
prerequisites list is optional.
best regards,
AW.
>As far as I know, you cannot create objects from interfaces, so the line
>below is wrong:
>
>I rewrote your code in this way and it worked correctly:
>
>namespace Test
>{
> public interface IFoo : Object
> {
> public abstract bool run();
> }
>
> public class Foo : Object, IFoo
> {
> public virtual bool run()
> {
> print("fuck\n");
> return true;
> }
> }
>
> public static void main()
> {
> IFoo ifoo = new Foo();
> ifoo.run();
> return;
> }
>}
>
>If you like to learn how to use polymorphisms in you apps you can see
>my tutorias
>on launchpad .
>I wish it can help you...
--
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
signature.asc
Description: PGP signature
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Dbus, connecting a signal to an async method...
On Sat, Dec 04, 2010 at 12:35:26 +0100, Marco Trevisan (Treviño) wrote: > Il giorno ven, 03/12/2010 alle 17.18 +0100, Abderrahim Kitouni ha > scritto: > > > session_proxy.name_acquired.connect (this.name_acquired); > > What I would have done is: > > > > session_proxy.name_acquired.connect ((name) => > > this.name_acquired.begin(name)); > > Ok, cool this works thanks. However in this case the lambda should be > (p, name) => this.nameacquired.begin(p, name); ;-) > > However I guess that this is just a workaround, the related bug should > be fixed! It's not a bug. The 'async' is part of the function signature, so the function signatures don't match and it can't be converted. It might be a missing feature, but I think it's preferable to explicitly require the .begin. > > You can also try to pass the begin method directly (but I'm not sure it > > works). > > No, I tried that, but it didn't work, I got an error since the begin > return value was considered just like a void. Hm, the begin function returns a void, but that's what the signal expects anyway, so it seems like that one should work. That would be a bug than. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Cannot have field and method with the same name
On Fri, Dec 03, 2010 at 15:38:38 -0800, Anatol Pomozov wrote:
> I have a class that contains a field and method with the same name,
> and Valac does not like it. What is the reason? Other languages
> (C#/Java) allow it.
Pardon me. C# does NOT allow that:
test.cs(3,17): error CS0102: The type `Foo' already contains a definition for
`stop'
Java allows it, but Java is one of very few languages where method isn't an
object (it is an object -- function pointer -- even in C and C++).
> You have to use () for method so you know whether
> you access method or field.
No, you don't. If there was just the method, this.stop would return
a delegate calling it, so when there's also field stop, the statement would
not be defined.
> public class Foo {
> public boolean stop = true;
>
> public boolean stop() {
> return true;
> }
> }
--
Jan 'Bulb' Hudec
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] vandr...@yandex.ru
vandr...@yandex.ru ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces - why do they must have prerequisites?
On Sun, Dec 05, 2010 at 17:32:17 +0100, Aleksander Wabik wrote: > I'm having class Foo, that is _NOT_ inheriting Object, but it's still > a typed class, and it's implementing interface IFoo. This is (or used to > be) legal. No, it is not and never was legal. Interfaces depend on runtime support provided by GObject and therefore only classes derived from GLib.Object may implement interfaces. -- Jan 'Bulb' Hudec ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces - why do they must have prerequisites?
>On Sun, Dec 05, 2010 at 17:32:17 +0100, Aleksander Wabik wrote: >> I'm having class Foo, that is _NOT_ inheriting Object, but it's still >> a typed class, and it's implementing interface IFoo. This is (or used to >> be) legal. > >No, it is not and never was legal. Interfaces depend on runtime support >provided by GObject and therefore only classes derived from GLib.Object may >implement interfaces. > Hi Jan, it was legal and in fact recent valac is still able to compile my other app, that is using interfaces that do not have GLib.Object as a prerequisite, and the class that implements these interfaces does not inherit Object too. As far as I remember, it has always worked this way, compact classes don't implement interfaces, but typed classes can dothis even if they don't inherit from GLib.Object. I'm attaching a file that shows it (GPL v.2). There's no main() method, but compiling it to C code (valac -C test.vala) works. This code is a part of a bigger project and in the executable app it has always worked. So obviously you don't have to inherit Object to be able to implement interfaces. 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 test.vala Description: Binary data signature.asc Description: PGP signature ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces - why do they must have prerequisites?
>On Sun, Dec 05, 2010 at 17:32:17 +0100, Aleksander Wabik wrote:
>> I'm having class Foo, that is _NOT_ inheriting Object, but it's still
>> a typed class, and it's implementing interface IFoo. This is (or used to
>> be) legal.
>
>No, it is not and never was legal. Interfaces depend on runtime support
>provided by GObject and therefore only classes derived from GLib.Object may
>implement interfaces.
>
Hi,
I think I've found the difference that causes this bug to reproduce or
not. In my whole program where it's not reproductible, I have never
declared interface instance as a local object (IFoo sth in the
function body); I create objects of class Foo, and assign them to
references of type Foo.
The interface is used in functions: function take argument of
interface type IFoo. It works! But if I try to create a reference of
interface type IFoo, error occurs. The demonstration code:
// test.vala
namespace Test
{
public interface IFoo
{
public abstract bool run();
}
public class Foo : IFoo
{
public virtual bool run()
{
return true;
}
}
public static bool test(IFoo ifoo)
{
return ifoo.run();
}
public static void main()
{
//IFoo ifoo = new Foo();
Foo ifoo = new Foo();
test(ifoo);
return;
}
}
//-- end test.vala --
This code will compile fine. But if I uncomment the commented line, and
comment the next one, it SHOULD compile fine too, but it fails with the
same error:
test.vala:23.3-23.6: error: missing class prerequisite for interface
`Test.IFoo', add GLib.Object to interface declaration if unsure
IFoo ifoo = new Foo();
So... it is a bug, right?
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
signature.asc
Description: PGP signature
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces - why do they must have prerequisites?
I am really sorry for flood, but it just came into my mind:
(CCing Jürg , as I think I've found a bug in the object system design)
>>On Sun, Dec 05, 2010 at 17:32:17 +0100, Aleksander Wabik wrote:
>>> I'm having class Foo, that is _NOT_ inheriting Object, but it's still
>>> a typed class, and it's implementing interface IFoo. This is (or used to
>>> be) legal.
>>
>>No, it is not and never was legal. Interfaces depend on runtime support
>>provided by GObject and therefore only classes derived from GLib.Object may
>>implement interfaces.
>>
>
>Hi,
>
>I think I've found the difference that causes this bug to reproduce or
>not. In my whole program where it's not reproductible, I have never
>declared interface instance as a local object (IFoo sth in the
>function body); I create objects of class Foo, and assign them to
>references of type Foo.
>
>The interface is used in functions: function take argument of
>interface type IFoo. It works! But if I try to create a reference of
>interface type IFoo, error occurs. The demonstration code:
>
>// test.vala
>namespace Test
>{
> public interface IFoo
> {
> public abstract bool run();
> }
>
> public class Foo : IFoo
> {
> public virtual bool run()
> {
> return true;
> }
> }
>
> public static bool test(IFoo ifoo)
> {
> return ifoo.run();
> }
>
> public static void main()
> {
> //IFoo ifoo = new Foo();
> Foo ifoo = new Foo();
> test(ifoo);
> return;
> }
>}
>//-- end test.vala --
>
>This code will compile fine. But if I uncomment the commented line, and
>comment the next one, it SHOULD compile fine too, but it fails with the
>same error:
>
>test.vala:23.3-23.6: error: missing class prerequisite for interface
>`Test.IFoo', add GLib.Object to interface declaration if unsure
> IFoo ifoo = new Foo();
>
>
>So... it is a bug, right?
>
>best regards,
>AW.
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:
- make ref and unref virtual functions - IMO it's bad, performance will
suffer,
- store ref and unref functions pointers in the interface somehow - can
it be achieved?? I guess it will be not possible, as interface can
not have fields? - and call these for references of the interface
type.
- have abstract ref and unref interface functions, that will have to be
implemented by the class that's implementing interface, and will
have to return proper ref and unref function pointers for that class.
- the only solution that can work, possibly? Performance for
references of class type will not suffer, but for the references of
interface type will suffer greatly...
- force all references of interface type to be unowned? - stupid, I can
define them unowned if I want, but if I don't want it, I'll accept the
performance hit for ref and unref.
Comments on this?
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
signature.asc
Description: PGP signature
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
