<?xml version="1.0" encoding="utf-8"?><!-- generator="wordpress/2.0.11" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: My Wandering Days Are Over</title>
	<link>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/</link>
	<description>Random babblings of a geek.</description>
	<pubDate>Sun, 06 Jul 2008 02:15:36 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.11</generator>

	<item>
		<title>by: ebassi</title>
		<link>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113410</link>
		<pubDate>Mon, 03 Sep 2007 16:09:17 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113410</guid>
					<description>@fct: yep, I've seen the thread on the mailing list; good stuff, let's hope it materialise soon - I can't wait. :-)

@juerg: sure, that's what I've learned anyway. and far from detracting your work, I think it's a perfectly valid design decision to enforce OOP - it's the template language (C#) that makes things harder. if you need a hand, I think I can work out a patch for the code generator.

@mathias: yeah, I know it's treated implicitly like that, but what's visible is "object.signal_name += handler" which is like adding apples to oranges and returning apples again. personally, I find this syntax flaky and a rape of the semantics of signal handling, but as I said above, it's the template language's fault, not Vala's.</description>
		<content:encoded><![CDATA[<p>@fct: yep, I&#8217;ve seen the thread on the mailing list; good stuff, let&#8217;s hope it materialise soon - I can&#8217;t wait. <img src='http://log.emmanuelebassi.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>@juerg: sure, that&#8217;s what I&#8217;ve learned anyway. and far from detracting your work, I think it&#8217;s a perfectly valid design decision to enforce OOP - it&#8217;s the template language (C#) that makes things harder. if you need a hand, I think I can work out a patch for the code generator.</p>
<p>@mathias: yeah, I know it&#8217;s treated implicitly like that, but what&#8217;s visible is &#8220;object.signal_name += handler&#8221; which is like adding apples to oranges and returning apples again. personally, I find this syntax flaky and a rape of the semantics of signal handling, but as I said above, it&#8217;s the template language&#8217;s fault, not Vala&#8217;s.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Mathias Hasselmann</title>
		<link>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113268</link>
		<pubDate>Mon, 03 Sep 2007 11:25:42 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113268</guid>
					<description>&#62; Come on: signal = signal + handler? Really?

The real story goes like this: signal_handler_list = signal_handler_list + handler</description>
		<content:encoded><![CDATA[<p>&gt; Come on: signal = signal + handler? Really?</p>
<p>The real story goes like this: signal_handler_list = signal_handler_list + handler
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: juergbi</title>
		<link>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113251</link>
		<pubDate>Mon, 03 Sep 2007 10:53:21 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113251</guid>
					<description>The support for classes not deriving from GObject is very new and we know that a lot of things are still missing there. I'd recommend to always derive your own classes from GObject unless there is a specific reason not to.
I agree that this snippet should fail to compile in Vala and that will also be the case in future versions, it just still misses quite some checks in the semantic analyzer. The idea in general is that it's a vala bug whenever the generated C code fails to compile, unless you're using invalid bindings.</description>
		<content:encoded><![CDATA[<p>The support for classes not deriving from GObject is very new and we know that a lot of things are still missing there. I&#8217;d recommend to always derive your own classes from GObject unless there is a specific reason not to.<br />
I agree that this snippet should fail to compile in Vala and that will also be the case in future versions, it just still misses quite some checks in the semantic analyzer. The idea in general is that it&#8217;s a vala bug whenever the generated C code fails to compile, unless you&#8217;re using invalid bindings.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: fct</title>
		<link>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113217</link>
		<pubDate>Mon, 03 Sep 2007 09:51:20 +0000</pubDate>
		<guid>http://log.emmanuelebassi.net/archives/2007/09/my-wandering-days-are-over/#comment-113217</guid>
					<description>The autotools support is under development right now:

http://bugzilla.gnome.org/show_bug.cgi?id=472048

As for the integration with gdb, there was some talk about that in the mailing list yesterday. Debugging is in the roadmap.

http://www.paldo.org/pipermail/vala/2007-September/thread.html#400</description>
		<content:encoded><![CDATA[<p>The autotools support is under development right now:</p>
<p><a href="http://bugzilla.gnome.org/show_bug.cgi?id=472048" rel="nofollow">http://bugzilla.gnome.org/show_bug.cgi?id=472048</a></p>
<p>As for the integration with gdb, there was some talk about that in the mailing list yesterday. Debugging is in the roadmap.</p>
<p><a href="http://www.paldo.org/pipermail/vala/2007-September/thread.html#400" rel="nofollow">http://www.paldo.org/pipermail/vala/2007-September/thread.html#400</a>
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
