Re: [Vala] Interfaces and asynchronous methods
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, here are the interesting pieces of the code:
interface backends : GLib.Object {
[...]
public abstract async BACKUP_RETVAL start_backup(out int64
last_backup_time);
[...]
}
private backends backend;
var rv=this.backend.start_backup(out this.last_backup_time);
BTW, Jim Nelson answered that I have to do something like this:
run_async.begin(on_run_async_completed);
/* ... */
void on_run_async(AsyncResult result, Object? source) {
int result = run_async.end(result);
}
Is this correct?
Thanks.
El 14/08/12 01:10, Eric Gregory escribió:
On Mon, Aug 13, 2012 at 4:03 PM, rastersoft ras...@rastersoft.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I tried to define an interface with an async method, but I receive this
error in the line where I try to invoke it in an object that
implements it:
backup.vala:246.14-246.43: error: invocation of void method not allowed
as expression
Are async methods not allowed in interfaces?
Thanks.
Could you paste the code that invokes the async method in this thread?
- Eric
- --
Nos leemos
RASTER(Linux user #228804)
ras...@rastersoft.com http://www.rastersoft.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAqHxsACgkQXEZvyfy1ha+sKgCgxRoFUf2QmxrUQVH5B4n+z21y
6UIAnA4xXKunyl1qz/GajMhKNu4kGj9w
=yxwF
-END PGP SIGNATURE-
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and asynchronous methods
out keyword in async method has a different approach.
See the tutorial about async method:
https://live.gnome.org/Vala/Tutorial#Asynchronous_Methods
They is there an example that look similar to yours:
async int fetch_webpage(string url, out string text) throws IOError {
// Fetch a webpage asynchronously and when ready return the
// HTTP status code and put the page contents in 'text'
[...]
text = result;
return status;
}And how to use it, and handle the output:
fetch_webpage.begin(http://www.example.com/;, (obj, res) = {
try {
string text;
var status = fetch_webpage.end(res, out text);
// Result of call is in 'text' and 'status' ...
} catch (IOError e) {
// Problem ...
}
});I think this example answers your question.
Tal
Date: Tue, 14 Aug 2012 11:49:15 +0200
From: ras...@rastersoft.com
To: e...@yorba.org
CC: vala-list@gnome.org
Subject: Re: [Vala] Interfaces and asynchronous methods
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, here are the interesting pieces of the code:
interface backends : GLib.Object {
[...]
public abstract async BACKUP_RETVAL start_backup(out int64
last_backup_time);
[...]
}
private backends backend;
var rv=this.backend.start_backup(out this.last_backup_time);
BTW, Jim Nelson answered that I have to do something like this:
run_async.begin(on_run_async_completed);
/* ... */
void on_run_async(AsyncResult result, Object? source) {
int result = run_async.end(result);
}
Is this correct?
Thanks.
El 14/08/12 01:10, Eric Gregory escribió:
On Mon, Aug 13, 2012 at 4:03 PM, rastersoft ras...@rastersoft.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all:
I tried to define an interface with an async method, but I receive this
error in the line where I try to invoke it in an object that
implements it:
backup.vala:246.14-246.43: error: invocation of void method not allowed
as expression
Are async methods not allowed in interfaces?
Thanks.
Could you paste the code that invokes the async method in this thread?
- Eric
- --
Nos leemos
RASTER(Linux user #228804)
ras...@rastersoft.com http://www.rastersoft.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAlAqHxsACgkQXEZvyfy1ha+sKgCgxRoFUf2QmxrUQVH5B4n+z21y
6UIAnA4xXKunyl1qz/GajMhKNu4kGj9w
=yxwF
-END PGP SIGNATURE-
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and asynchronous methods
On Tue, Aug 14, 2012 at 2:49 AM, rastersoft ras...@rastersoft.com wrote:
BTW, Jim Nelson answered that I have to do something like this:
run_async.begin(on_run_async_completed);
/* ... */
void on_run_async(AsyncResult result, Object? source) {
int result = run_async.end(result);
}
Is this correct?
Jim's right, you can't just call an async method directly; you need to call
.begin() and follow up with a completion method. Once you're inside an
async method, you can use yield to call other async methods.
You should give this a read, it explains async usage really well:
https://live.gnome.org/Vala/Tutorial#Asynchronous_Methods
Some further examples here:
https://live.gnome.org/Vala/AsyncSamples
- Eric
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Interfaces and asynchronous methods
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all: I tried to define an interface with an async method, but I receive this error in the line where I try to invoke it in an object that implements it: backup.vala:246.14-246.43: error: invocation of void method not allowed as expression Are async methods not allowed in interfaces? Thanks. - -- Nos leemos RASTER(Linux user #228804) ras...@rastersoft.com http://www.rastersoft.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAph9IACgkQXEZvyfy1ha90oACgygrG7j62MYYCI3l4p5PKA39H eKwAnjVQAa42eSNDYpwumWgQDlpUOyTX =V5pj -END PGP SIGNATURE- ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and asynchronous methods
On Mon, Aug 13, 2012 at 4:03 PM, rastersoft ras...@rastersoft.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all: I tried to define an interface with an async method, but I receive this error in the line where I try to invoke it in an object that implements it: backup.vala:246.14-246.43: error: invocation of void method not allowed as expression Are async methods not allowed in interfaces? Thanks. Could you paste the code that invokes the async method in this thread? - Eric ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] interfaces
following compiles without warning/error but at runtime it tells me
(process:6285): GLib-GObject-WARNING **: cannot add interface type
`JJJ' to type `BBB' which does not conform to prerequisite `III'
/* [public|private] interface name {
** constant/method/delegate/signal
** }
*/
interface III {
public const int i = 2 ;
public abstract void m ();
}
interface JJJ : III {
// public void m () { stdout.printf(J.m() ueberdeckt I.m(). 'new'
ist nicht erforderlich\n); }
public void n () { stdout.printf(J.n()\n); }
}
abstract class AAA {
}
class BBB : AAA,JJJ,III {
int _j ;
public double d ;
public int j { get{return _j;} set{_j=value;} }
public BBB(){ j=i+12; d=1.23; }
public void m() { stdout.printf(I.m() in class B implementiert\n); }
}
int main ( string[] args ) {
var b = new BBB();
stdout.printf(%d %d %f\n,((III)b).i,b.j,b.d);
b.m();
b.n();
return 0 ;
}
when 'class A : J/*,I*/ {}' a similiar error at compile time.
is there actually need to declare all interfaces in class-declaration, i.e.
interface i1 {} ; interface i2:i1 {} ... interface i99:i98 {}
class C : i99,...,i1 {}
???
thanks in advance
andreas
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] interfaces
On 07/06/2012 08:56 AM, andreas graeper wrote:
following compiles without warning/error but at runtime it tells me
(process:6285): GLib-GObject-WARNING **: cannot add interface type
`JJJ' to type `BBB' which does not conform to prerequisite `III'
[snip]
is there actually need to declare all interfaces in class-declaration, i.e.
interface i1 {} ; interface i2:i1 {} ... interface i99:i98 {}
class C : i99,...,i1 {}
???
Yes, you need to declare all interfaces. This is the way Vala and
GObject were designed.
The order in which you list interfaces in the class declaration matters:
class BBB : AAA,III,JJJ {
will work.
This is arguably a (minor) bug. It was reported last year:
https://bugzilla.gnome.org/show_bug.cgi?id=656204
___
vala-list mailing list
vala-list@gnome.org
https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] interfaces sharing methods
On Sat, Jun 2, 2012 at 10:35 PM, Jarosław Ciupiński kotow...@gmail.comwrote: Hi, Recently I run into a problem of interfaces sharing methods. I have two interfaces that have method of the same name, same result, same parameter list - it is done on purpose this way, so interfaces would require such method to be implemented. Vala doesn't support it yet. See https://bugzilla.gnome.org/show_bug.cgi?id=652098 -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] interfaces sharing methods
On Tue, Jun 5, 2012 at 7:08 PM, Simon Busch morp...@gravedo.de wrote: I got at a point recently where I had the same problem. Is this going to be happen in Vala anytime soon (say 0.18)? It's planned for sure, but don't know when. -- www.debian.org - The Universal Operating System ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] interfaces sharing methods
Hi, Recently I run into a problem of interfaces sharing methods. I have two interfaces that have method of the same name, same result, same parameter list - it is done on purpose this way, so interfaces would require such method to be implemented. It compiles fine. But it crushes when run. I checked c code and found out that although both interfaces are defined fine, when they are set up, only one of them has shared method set up properly. Other one doesn't mention the method (so it is either 0 or undefined, I didn't check that). I would love to have it working by setting up shared method properly for both interfaces (that would be great and would be another unique and useful thing in vala), although disallowing that by throwing an error during compilation could also be fine as you can work around it by creating third interface and making it a prerequisite for both interfaces. Regards, Jarek Ciupinski (I love vala for two reasons: 1 it is a language that makes lots of things easier, 2 I have no problems with using same code under both Windows and Linux - it is maybe worth mentioning that I work on a game and it isn't main purpouse of vala creation and I don't know if it was considered as a language for game creation). ___ vala-list mailing list vala-list@gnome.org https://mail.gnome.org/mailman/listinfo/vala-list
[Vala] interfaces and properties
Hi,
Why is it that one *doesn't* have to use override when implementing a
property declared on an interface? I.e.:
interface Animal
{
public abstract GenericArraystring names_of_bones { get; set; }
}
class Dog : Object, Animal
{
public GenericArraystring names_of_bones { get; set; }
}
works.
If I try:
public override GenericArraystring names_of_bones { get; set; }
valac complains with no suitable property found to override.
And the problem is that this also works (!):
interface Animal
{
public abstract GenericArraystring names_of_bones { get; set; }
}
class Dog : Object, Animal
{
public GenericArrayint names_of_bones { get; set; }
}
which leads to serious bugs.
Am I missing something?
Cheers,
Raúl
___
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?
Hello, في ن، 06-12-2010 عند 01:25 +0100 ، كتب Aleksander Wabik: 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). Yes, that's exactly the problem. 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: What's exactly your problem with having common ancestor? AFAIK, every type system out there requires all of your objects (whether they implement an interface or not) to have a common ancestor. So why Vala's all objects implementing a given interface must have a common ancestor a problem? And it's recommended to always inherit from GLib.Object unless the performance gain is real (you're creating really many objects), and even then creating a light base class for your app's classes to inherit from wouldn't have much more overhead than implementing an interface in the first place. HTH, Abderrahim ___ 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 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 ___ 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?
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 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?
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 https://launchpad.net/vala-totrials.
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] 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 b...@ucw.cz ___ 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
[Vala] Interfaces - why do they must have prerequisites?
Hi all,
I'm using valac 0.11.2, and when I compile the following code, it fails:
// --- 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 -
The compiler fails with the following error:
$ valac test.vala
test.vala:18.3-18.6: error: missing class prerequisite for interface
`Test.IFoo', add GLib.Object to interface declaration if unsure
IFoo ifoo = new Foo();
test.vala:18.3-18.6: error: missing class prerequisite for interface
`Test.IFoo', add GLib.Object to interface declaration if unsure
IFoo ifoo = new Foo();
Compilation failed: 2 error(s), 0 warning(s)
When I make IFoo dependant on Object, and Foo inheriting Object, the
problem is gone.
Please can you tell me, is now prerequisiting interface on a class
always needed? http://live.gnome.org/Vala/Manual/Interfaces suggests
that it's optional...
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 and Mixins
On Tue, Jun 15, 2010 at 16:09:06 -0700, Robert Powell wrote: On Tue, Jun 15, 2010 at 4:00 PM, tecywiz121 tecywiz...@hotmail.com wrote: Actually in my other interfaces, it works fine. I'm just not sure if I'm allowed to override a method declared in Flushable in Entity. Do your other interfaces derive from another interface? I think that is where trouble lies, or used to lie. Well, the problem is that interfaces don't derive from each other, they *depend* on each other. They therefore can't override each other's method -- they can only call them. I think the best you can do is to have a helper method in the Entity interface and use it to implement Flushable in the concrete class. -- Jan 'Bulb' Hudec b...@ucw.cz ___ vala-list mailing list vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and Mixins
On Sat, Jun 12, 2010 at 7:03 AM, tecywiz121 tecywiz...@hotmail.com wrote:
Hey,
Hey!
The following code won't compile unless I create a flush() in Concrete,
but I can't seem to access Entity.flush() at all, any way around this
that doesn't involve making Entity a class?
public interface Flushable : Object
{
public abstract void flush();
}
public interface Entity : Object, Flushable
{
public virtual void flush()
{
// Do Something
}
}
What are you trying to accomplish by having both Flushable and Entity? I
think you are trying to create different mixin implementations of Flushable,
which seems like a perfectly reasonable thing to do.
You can access Entity.flush by casting this to an Entity. I think you'll
find that when you refer to the object you will receive GObject warnings
about cannot add interface type 'Entity'. Even without the name collision
of flush, this GObject warning will still occur.
Deriving interfaces from interfaces is definitely broken. You might want to
submit a bug.
Hope that helps,
Rob
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and Mixins
On Tue, 2010-06-15 at 14:50 -0700, Robert Powell wrote:
On Sat, Jun 12, 2010 at 7:03 AM, tecywiz121 tecywiz...@hotmail.com
wrote:
Hey,
Hey!
The following code won't compile unless I create a flush() in
Concrete,
but I can't seem to access Entity.flush() at all, any way
around this
that doesn't involve making Entity a class?
public interface Flushable : Object
{
public abstract void flush();
}
public interface Entity : Object, Flushable
{
public virtual void flush()
{
// Do Something
}
}
What are you trying to accomplish by having both Flushable and Entity?
I think you are trying to create different mixin implementations of
Flushable, which seems like a perfectly reasonable thing to do.
I am trying to have a type hierarchy like so
Flushable
| \
| \
Entity \
|\
| FlushableNonEntity
SomeObj
Where SomeObj's implementation of Flush comes from entity, but
FlushableNonEntity's does not.
You can access Entity.flush by casting this to an Entity. I think
you'll find that when you refer to the object you will receive GObject
warnings about cannot add interface type 'Entity'. Even without the
name collision of flush, this GObject warning will still occur.
Wouldn't the following code (not sure, haven't tried) just recurse
infinitely?
public object Bob : Object, Flushable, Entity
{
public void flush()
{
((Entity)this).flush();
}
}
Deriving interfaces from interfaces is definitely broken. You might
want to submit a bug.
Actually in my other interfaces, it works fine. I'm just not sure if
I'm allowed to override a method declared in Flushable in Entity.
Hope that helps,
Rob
It kinda does, thanks
Sam
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Interfaces and Mixins
On Tue, Jun 15, 2010 at 4:00 PM, tecywiz121 tecywiz...@hotmail.com wrote:
On Tue, 2010-06-15 at 14:50 -0700, Robert Powell wrote:
On Sat, Jun 12, 2010 at 7:03 AM, tecywiz121 tecywiz...@hotmail.com
You can access Entity.flush by casting this to an Entity. I think
you'll find that when you refer to the object you will receive GObject
warnings about cannot add interface type 'Entity'. Even without the
name collision of flush, this GObject warning will still occur.
Wouldn't the following code (not sure, haven't tried) just recurse
infinitely?
public object Bob : Object, Flushable, Entity
{
public void flush()
{
((Entity)this).flush();
}
}
As long as Entity's implementation of flush doesn't call Bob's
implementation of flush, I don't see why it would recurse.
Deriving interfaces from interfaces is definitely broken. You might
want to submit a bug.
Actually in my other interfaces, it works fine. I'm just not sure if
I'm allowed to override a method declared in Flushable in Entity.
Do your other interfaces derive from another interface? I think that is
where trouble lies, or used to lie.
Rob
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
[Vala] Interfaces and Mixins
Hey,
The following code won't compile unless I create a flush() in Concrete,
but I can't seem to access Entity.flush() at all, any way around this
that doesn't involve making Entity a class?
public interface Flushable : Object
{
public abstract void flush();
}
public interface Entity : Object, Flushable
{
public virtual void flush()
{
// Do Something
}
}
public class Concrete : Object, Flushable, Entity
{
public static int main(string[] args)
{
stdout.printf(Hello World\n);
return 0;
}
}
___
vala-list mailing list
vala-list@gnome.org
http://mail.gnome.org/mailman/listinfo/vala-list
Re: [Vala] Bug: Implementing properties in vala Interfaces fails with Genie
^ Compilation failed: 6 error(s), 0 warning(s) P.S.: used latest git commit 66d126e6bebca5cb6ea286979764b3ce15da24a7 ___ Vala-list mailing list Vala-list@gnome.org http://mail.gnome.org/mailman/listinfo/vala-list
