Re: Object or <T> parameters

Bryn Keller <[email protected]> Tue, 24 Feb 2004 16:39:24 -0800
Newsgroups gmane.comp.lang.nice.general
Message-ID <[email protected]>
[email protected] wrote:

>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? 
>  
>
I think it's reasonable. It might be nice to have it print name, type 
information, and so on. Even if it doesn't, I don't see what the issue 
is. If it's first class, you ought to be able to inspect it, IMHO.

>>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.
>
Perhaps, but I'm not so sure. If we can construct functions at runtime 
via reflection or some similar mechanism, then functions are definitely 
instances! I'm not sure it's helpful to say they're not instances.

> And, you could say "functions and instances are first-class objects"
>and "values of primitive types are not objects" which makes sense too.
>  
>
Does it? I'm not sure about that either.

>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)); // ???
>    }
>  
>
Did you mean "let d = newInstance(getClass(c))"? I would think it would 
create a new method. This would fail at runtime I imagine, since methods 
probably wouldn't have no-arg constructors.

>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()
>         }
>     }
>  
>
Helpful in that case, but not in this:

<T,U> List<U> callEach(List<T->U> funcs, T arg) {
   List<U> result = new ArrayList();
  for(T->U func : funcs) {
    println("Calling " + func);
    result.add(func(arg));
  }
}

>It is basically the same motivation that you had for delayed<T> in the
>expression-local variables thread, namely catching likely typos during typechecking.
>  
>
A worthwhile goal, but I'm not convinced that benefits outweigh the costs.

Bryn


-------------------------------------------------------
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