functions as objects

More from Object Thinking, on the everything is an object thread.

In an object thinker’s programming language, the elements of the language can also be objects. So, a method on a class should be objects. Given a class ‘C’ and a method ‘F’, I should be able to write:

     C.F.

And get a completion list of things to do to a method. Things like:

· Invoke

· IsExecuting

· event OnStart

· event OnEnd

· get_Statements

If class ‘C’ has methods ‘F’ and ‘G’, can I do:

          C.F = C.G

?

No, this should be prohibited. But the reason is important. It should be allowed by the language, but prohibited by ‘C.F’. Not because assigning to methods is illegal, but because methods are immutable.

You get some of this with .NET Reflection, but it’s not quite as powerful as what I could imagine, and it doesn’t really have the first-class language status I’m looking for.

Comments

• Anonymous
  June 08, 2004
  I am not sure how to express this, but it seems that you would need some kind of static/dynamic system.
  
  Would C.F() be a short hand for C.F.Invoke?
  
  Does Invoke return an instance of F? or is there only one instance of F, which the instance of C references as long as it is alive?
  
  Why wouldn't statements be objects then too? (Oh the overhead!)
  
  
• Anonymous
  June 08, 2004
  What you are describing, esentally, is an object oriented extension of higher order methods, which are common in languages like ML and lisp. Whidbey, however, already has support for higher order methods-objects through anonymous delegates. Being able to do "c.F." and getting a completion list is really just syntatic sugar for "new Delegate() {c.F()}." and getting a completion list...
• Anonymous
  June 08, 2004
  It seems to me that you don't want this behavior for functions 90+% of the time.
  
  In the cases where you want your functions to have these characteristics is the point where you escalate them from a function to an object itself.
  
  I do agree that the ability to use metadata for functions is a good thing. Pushing that into the language is an interesting idea.
  
  It has been fun noodling on this. Thanks
• Anonymous
  June 08, 2004
  By making "C.F." syntatic sugar for "new Delegate(){c.F()}." you get the best of both worlds. In particular, the function is not treated like an object utill you try to access it like an object. Supporting using "C.F." just prevents you from having to type "new Delegate() {c.F()}." all the time. It also better supports thinking of functions as objects.
• Anonymous
  June 08, 2004
  The comment has been removed
• Anonymous
  June 08, 2004
  Yea....
  
  Also to enable the observeration of ordinary method invocation as you indicated in your example (OnStart, OnEnd), would either require all methods be represented as delegates, or modifications to be made to the language to support before and after methods. So not everything you were aiming for could be reduced to syntatic sugar, but a more restricted version could.
  
  
• Anonymous
  June 08, 2004
  Do any languages currently support this fully?
• Anonymous
  June 08, 2004
  "Do any languages currently support this fully?"
  
  Smalltalk.
• Anonymous
  June 08, 2004
  Objective-C
• Anonymous
  June 14, 2004
  You can take a look at
  http://www.nemerle.org/grokking.html#functionals
  where we have functional types, which can be treated like common objects.
  
  We can do
  class A {
  public mutable f : string -> void;
  
  public this () {
  f = fun (x) {
  WriteLine ("invoking " + x)
  }
  }
  }
  
  and at any time do
  
  def x = A();
  x.f = fun (y) {
  WriteLine ("my_invoking " + y)
  };
  x.f ();
  
  This kind of stuff is common practice in ML/functional languages