[Checkers] Various Notes Part 2: Type System IGJ
Yoav Zibin
yoav.zibin at gmail.com
Sun Apr 27 17:10:20 EDT 2008
Two comments:
4) About:
interface UnaryOp<Return, Param> {
/**
* Apply the unary operator to the parameter
* @return the result of the operation
*/
public Return apply(Param param);
}
In this case, @ReadOnly UnaryOp<@Mutable Date> is not a subtype of @ReadOnly
UnaryOp<@ReadOnly Date>.
*Read in the IGJ paper the section about erased-method signature and the
example with Comparable.compareTo(T t)
*
5) Can you give an example of your problem with the visitor pattern?
I didn't understand your problem (so of course I couldn't understand the
solution :)
finally, I'm leaving Boston tomorrow morning because things didn't work out
with the girl I came to see (Lily).
I'm sorry I didn't have a chance to meet neither Mahmood nor Mike :(
Best regards,
Yoav
On Sun, Apr 27, 2008 at 1:50 PM, Mahmood Ali <mahmood at mit.edu> wrote:
> Hi again,
>
> Here is my second part in the two-part series.
>
> NOTES ABOUT TYPE SYSTEMS AND IGJ IN PARTICULAR
>
> 1. Support for Arrays is essential
> Personally, I was surprised by the usage of arrays in almost all case
> studies I have done yet!
>
> ==========================================
>
> 2. I don't like AssignsFields nor any annotation like it (is Raw
> annotation like it?)
>
> Type Qualifiers on method receivers have multiple meanings:
> * Documenting the side effect of the method. (e.g. Mutable, ReadOnly in
> IGJ and Javari)
> * Restrict the types on which the method can be dispatched (e.g. Mutable,
> ReadOnly, and Interned, etc)
>
> Simply put, the type qualifier provides an documented interface for
> *using* the method.
>
> AssignsFields does not quite do that. It does not provide an provide an
> interface (for an outside class it is treated as Mutable). It simply means
> 'constructor can call this method safely', which is an implementation
> detail, and it impacts how the method is implemented and how any overrider
> method can be implemented!
>
> While the programmer can easily deal with the raised issues, the solutions
> are not elegant.
>
> : Lesson learnt: Never annotate an interface method receiver as
> AssignsFields! Be careful with abstract classes!
>
> By tomorrow I will have an estimate how AssignsFields is actually
> impacting the implementation!
>
> ==========================================
>
> 3. Projects have different philosophies
>
> In most of the projects, imperative programming style dominated the style;
> but with a few there were some functional style too. However there is no
> much overlap between them. In many of the case studies I found almost no
> @Immutable annotation (like JOlden, JavaCrond), while others like functor2
> (library for functional programming, with lot of immutable java.util.Map and
> functional mappers and reducers) is basically all @Immutable references!
>
> Furthermore, most classes I dealt with did not represent datatypes, but
> rather they were "service" classes, like java.io classes, connectivity
> classes, diff creation classes, database classes, etc.
>
> Even some datatype classes are actually service classes.
> java.sql.ResultSet for example, is a datatype to wrap the result received
> from database statement call. Yet it actually represents a live connection
> to the database with a close(). In a sense you can never have an immutable
> result set, because at any point the creator statement closes which would
> close the result set and then all the sudden the values in ResultSet are not
> there anymore! Similarly all the updator methods are updating the back-end
> database.
>
> I don't necessary consider this as weakness in the IGJ type system, but
> rather an indication of a bad design!
>
> ==========================================
>
> 4. Allowing type argument qualifiers to change covariantly for collection
> is not general.
>
> IGJ allows type qualifiers to change covariantly in type arguments for
> collections:
> @Mutable List<@Mutable Date> <: @ReadOnly List<@ReadOnly Date>
>
> However, this rule is not constitute a general sound rule. Consider an
> interface wrapping a unary operation (method with one parameter). The
> interface may be defined as:
>
> interface UnaryOp<Return, Param> {
> /**
> * Apply the unary operator to the parameter
> * @return the result of the operation
> */
> public Return apply(Param param);
> }
>
> In this case, @ReadOnly UnaryOp<@Mutable Date> is not a subtype of
> @ReadOnly UnaryOp<@ReadOnly Date>.
>
> I only saw this style of programming in functor2, I haven't tried to deal
> with this quite yet.
>
> ==========================================
>
> 5. We might like to consider allowing '@I' be a method receiver
>
> Motivation: visitor and call-back currently cannot really be immutable.
>
> Problem: Currently, I can either annotate visitor method receivers with
> Mutable or ReadOnly. If I annotate them as Mutable, I cannot have an
> immutable visitor; and I annotate them as ReadOnly I cannot have a mutable
> visitor or I would need to use a lot of hacks using Mutable and Assignable
> fields
>
> Proposed solution:
> For documentation purposes, '@I' as method receiver within *interfaces*,
> means that this method may mutate or not depending on the immutability of
> the subclasses; however, it does not say anything regarding its
> invocation-ability (is this a word?)
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://lists.csail.mit.edu/mailman/private/checkers/attachments/20080427/0ee12854/attachment.htm
More information about the checkers
mailing list