Re: Object or <T> parameters

Quoting Daniel Bonniot <[email protected]>:

> [email protected] wrote:
> 
> >Shouldn't the type system ensure that the following example doesn't
> compile:
> >
> >void my_println(Object o) {
> >	println(o);
> >}
> >
> >void main(String [] args) {
> >	let a = () => "hello";
> >	my_println(a);
> >}
> >
> >It seems like we are much more likely to want to have written:
> >
> >void main(String [] args) {
> >	let a = () => "hello";
> >	my_println(a());
> >}
> >  
> >
> I think this is pretty specific to the fact that toString is available 
> on any value, and therefore println also.

Why should toString() be available for functions? It is reasonable to make it do
anything useful? If not, then I think toString() shouldn't accept functions as
arguments.  Do any of the methods in java.lang.Object make sense for functions?
Don't you think it is reasonable to believe that some methods make sense for
instance objects but not for functional values? 

> To get more static checking, it would be interesting to have a 
> "Showable" (hello magnus!) or otherwise named abstract interface, so 
> that classes clan declare if they implement in a meaningful way a method 
> that represents their instances as strings. One obstacle to that is the 
> variance issue, but that will be solved eventually ;-)

I don't know what you mean by "variance issue." 
 
> >In particular, I think that arrow types should not be considered subtypes
> of
> >Object. Then, we have:
> >  
> >
> I think that would be giving the wrong message. Hey, in Nice, functions 
> are not really objects, they are not like other values, they are not 
> really first class!

That is because the name "Object" is not good. Imagine if java.lang.Object was
java.lang.Instance. In fact, you could even have native class Instance =
java.lang.Object; Then you would say "functions are not really instances" which
is true. And, you could say "functions and instances are first-class objects"
and "values of primitive types are not objects" which makes sense too.

For example, why should the following program typcheck? What does
newInstance(getClass(() => true)) mean?:
    void main(String [] args) {
        let a = new Date();
        let b = newInstance(getClass(a));
        let c = () => true;
        let d = newInstance(getClass(a)); // ???
    }
That is, it seems that getClass should have type:
     <Object T> Class<T> getClass(T);
Where <Object T> means "not a function," possibly also "not a primitive type."

Do you think it is not helpful to be able to catch mistakes like this?:
     <T> T iterate(int times, void -> T fun) {
         for (int i = 0; i < times; ++i) {
            log(times + "th iteration: " + fun);
            // oops, I meant fun()
         }
     }

It is basically the same motivation that you had for delayed<T> in the
expression-local variables thread, namely catching likely typos during typechecking.

> >If you try to compile a function like:
> >    <Object T> void doSomething() { }
> >The compiler reports:
> >    Object is not a class
> >This is strange because "Any" is not a class either but it is allowed.
> Isn't
> >"Any" the same kind of thing "Object" is?
> >  
> >
> Any is nothing at all, really ;-)
> It's a piece of syntax, hapilly ignored after the parser has read it. I 
> would probably recommand to simply wite <T> for an unconstrained type 
> parameter. Would dropping 'Any' make things clearer?

I think getting rid of "Any" and "Some" in their current usages is a good idea
since there is already a better (IMO) syntax for expressing those things.

- Brian






-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click