Re: Precise types & retyping

Quoting Daniel Bonniot <[email protected]>:

> >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" 
> 
> "I" might not be the same person. These two people can decide to 
> consider imported Java methods with different types for valid reasons, 
> because:
>   1) There might not be a "true" type for it, since as I said Java 
> methods are often underspecified.

Sure, but if they are working on the same program then they can agree on the
retypings, right? I am only saying that the same retypings for a method should
be used during a single compilation. So, you might have a whole set of retypings
for SWT in CVS for your project, I might have a different set of retypings for
SWT in my CVS tree for my project, and that is okay as long as we don't try to
compile our two projects together at once. 

>   2) They might choose different levels of static checking. I know that 
> this might sound strange. In pure Nice code, you don't get this choice, 
> and that's completely deliberate. But using Java code makes the 
> situation a bit different. Consider this: in Java, you can set the value 
> of System.out. Which means that you can set it to null, brain dead as 
> this idea might be. Should all printing code look like:
>   let out = System.out;
>   if (out != null) out.println("...");
> That does not sound reasonable. In nice.lang I decided to retype also 
> setStdout so that setting System.out to null is not possible from nice 
> code. But you have no guarantee a Java method you call will not do it.
> This situation can happen with various degrees of likeliness for the 
> "exceptional case" to occur, in which case individual programmers might 
> make different decisions about what type to give.

Yes, I understand that. But, why would you want System.out or any method/field
to have two different types while compiling a _single_ program? I don't see how
it is helpful. Conversely, it seems like a good indication of a mistake if I
have assumed that a single method has two types in different parts of my
_single_ program, so I want the compiler to catch this situation for me.

> >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. 
> >
> It seems you are assuming that there is only one author, a world-wide 
> central repository of retypings or no independent development of 
> packages, which does not seems reasonable.

No, I am just assuming that all the people that work on a particular project
would share a set of retypings for the libraries that they use in that program.
So, for example, the people who write Flow4J would all agree on a particular set
of retypings for Flow4J and check them into its CVS tree. But, the people who
wrote the Nice Eclipse pluging could have a completely different set of
retypings for their project in its CVS tree. Of course, there could also be a
central repository of "official" retypings but that it independent of what I am
suggesting here.

> Besides, there is no issue with different packages making different 
> assumptions being combined. The retypings only affect the internals of 
> the packages, not their public interface.

The thing I don't like is that if I want to change the retyping for a single
method then I have to search/replace through multiple source files to do it. For
example, if I discover that some method sometimes returns null when I had
previously assumed it never would, I cannot make a centralized change that would
guarentee that all my code that assumed it would return a not-null value would
be flagged as erroneous during the next compilation.

- 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