Re: Precise types & retyping

Quoting Daniel Bonniot <[email protected]>:

> 
> >If I have two packages:
> >
> >Package A:
> >
> >    import org.eclpise.swt.* (!);
> > 
> >Package B:
> >    
> >    import org.eclipse.swt.*;
> >
> >Now, everything in org.eclipse.swt has two types? That doesn't make sense. 
> >
> No. That means that in package A you choose a certain policy, in B a 
> different one.

I don't understand. What is a "policy"? Isn't it true that when compiling
package A, different types will be used for methods in org.eclipse.swt than are
used when compiling package B? Or, in other words, each method in
org.eclipse.swt is given two types (one for package A, one for package B)?

> I agree that normally there should be an "ideal" retyping for a given 
> Java library. It's not always obvious, though, because many methods do 
> not specify if they accept null arguments, under what circumstances, if 
> any, they can return null, ...

I know, but I think that the compiler should enforce that the same set of
retypings is used in each importing package for a given program. It doesn't make
sense to say "I _know_ this method accepts null values for its parameters" in
part of a program and then in another part of the same program, say "I _know_ it
doesn't accept null values for its parameters" (similarly, I _know_ this method
never returns null when compiling package A, but somehow I don't know that when
compiling package B). 

> >I
> >suggest that you move this package-level retyping to the package
> declaration:
> >
> >org/eclise/swt/typing.nice:
> >package org.eclise.swt (!);
> >// retypings/renamings of specific methods/constructors/etc follow
> >  
> >
> There is no package declaration for swt. It lies in a jar on your 
> classpath, that's all.

My suggestion was that the user should create a file
"org/eclise/swt/typing.nice" that contains the package declaration, and possibly
other specific retypings for that package, so that all retypings for
classes/methods in org.eclipse.swt are defined in this file (and _only_ this
file). This way, every field and every method is prescribed exactly one type for
all source code of the entire program. If you can't say this, then what exactly
does it mean to say "method X has type T" in Nice?

> >you could pull retypings out of the grammar for Nice files and require that
> >retypings be in seperate *.typing files that only allow retypings. 
> >
> Yes, but that would need a specfication of .typing files. The import 
> statement seems like a logical place to specify how that package is 
> retyped by default.

I was suggesting that the current syntax for retyping be used in the *.typing
files, with the addition of the "package ... (!)" syntax mentioned above,
disallowing "import ... (!)" and retypings from all *.nice files.

> I'm all for centralizing retypings for commonly used libraries, so that 
> this work can be shared. That's one of the things NiceSwing does, and 
> that NiceSWT will. Still, there are some less popular library that can 
> be useful to only a few users, so it's useful to have a convenient way 
> to use them.

Sure, having a central repository for retypings is orthogonal for how the
retypings are specified in the source code.

- 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