logo       

Re: Dropping BeginInvoke overloads: msg#00108

lang.boo.devel

Subject: Re: Dropping BeginInvoke overloads

3 is fine. How about methods with a special attribute that get run at compile-type given their arguments as AST expressions and that can modify the AST? This would be an easy way for _expression_ macros; they could either be global in a module or in an extension class (public extensions class System.Delegate: ...)

Daniel

Rodrigo B. de Oliveira wrote:
So functions/methods are first class values in boo.

You can define a function 'spam':

    def spam():
		print 'spam! spam! spam!'
		
and then use it as an object. You can say, among other things:

	a = spam
    spam.Invoke()
    spam.BeginInvoke({ print 'called back' }, null)

The runtime demands BeginInvoke to have the signature: (AsyncCallback, object).

Boo currently allows you to write simply:

    spam.BeginInvoke()

This is the same as passing null for the other args, the compiler supports this
by overloading BeginInvoke on the underlying delegate definition.

Unfortunately, the latest .net 2.0 CTP does not like BeginInvoke
overloading anymore.

This leaves us with 3 options:

    1) dropping BeginInvoke overloading entirely
	2) using a different name for the BeginInvoke overloads
	3) implement BeginInvoke overloading through inlining (removing the
overloads just before the emit step)
	
Right now, I'm going for 1 with a jira issue that reminds us to implement 3.

This only affects the .net 2.0 build.

Thoughts?

bamboo


  

<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise