[chuck-users] static function overloading

[Stefan Blixt]

ChucK often seems inspired by Java, and I suspect that's the case here.
 Static functions and variables in Java works just like you describe for
ChucK - the class is here basically just a kind of namespace that wraps the
methods and variables, since they live outside the object oriented world of
instances.
In Java, static items are always specified using that namespace, e.g.:

class A {
 static int v;
}

int b = A.v;

Inside classes, you can omit the class name, which is implied:

class A {
  static int v;

  int f() {
    int b = v;
  }
}

You can reuse a static name in a subclass. However, this is not the same as
overloading, since you always specify the class containing the static
member, and if you don't specify it it is implied that it is in the same
class:

public class A {

static int f() {

return 1;

}

 static int test() {

return f();

}

}


public class B extends A {

static int f() {

return 2;

}

 static int test() {

return f();

}

}


A.test() will return 1 and B.test() will return 2. This code would work
exactly the same if we removed the extends - static code bypasses the object
stuff.


Maybe the ChucK people thought this behaviour might make for hard-to-read
code, and simply banned reuse of static method names? There is no other
reason I can see why this isn't allowed. I'm personally a bit confused abut
the static concept in ChucK, since we can put stuff on "the ground" outside
class space, but maybe it's useful for the include file trick.


/Stefan



On Tue, Sep 8, 2009 at 6:06 PM, Kassen <signal.automatique at gmail.com> wrote:

> Stefan;
> > I forget - what separates static functions from other kinds of functions?
>
> They can only reference other static members and variables. That may
> sound like a downside but it also means they can be called without a
> object instance.
>
> This becomes useful in the case of functors (see the recent forum
> discussion), for example. Right now if we want overloading we also
> must create object instances of all extended classes. Right now this
> isn't much of a issue aside from me finding those extra lines ugly
> because they don't actually do anything useful (well, aside from
> making it work at all), but I anticipate problems if/when the much
> desired include functionality would get here.
>
> I would like to be able to extend classes without needing a object
> instance when instances don't actually do anything meaningful in the
> case that I might have.
>
> To me this seems like a solid case but it wouldn't be the first time
> that the nice people with ".cs." in their email address would expose
> me for the hack that I am ;-). The error message implies that the
> matter has been given some thought but I don't get what the reasoning
> is.
>
> Kas.
> _______________________________________________
> chuck-users mailing list
> chuck-users at lists.cs.princeton.edu
> https://lists.cs.princeton.edu/mailman/listinfo/chuck-users
>



-- 
Release me, insect, or I will destroy the Cosmos!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cs.princeton.edu/pipermail/chuck-users/attachments/20090908/566ebe25/attachment.html>