[ nice-Bugs-1096722 ] requires doesn't work like assert. SHould

Bugs item #1096722, was opened at 2005-01-05 21:55
Message generated for change (Comment added) made by bonniot
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=1096722&group_id=12788

Category: None
Group: None
>Status: Closed
>Resolution: Rejected
Priority: 5
Submitted By: mike.beckerle (mbeckerle)
Assigned to: Nobody/Anonymous (nobody)
Summary: requires doesn't work like assert. SHould

Initial Comment:
int foo(Object arg) requires (arg instanceof Integer)
{
  // assert(arg instanceof Integer); // redundant 
  return arg.intValue();
}

Version 0.9.10

Problem is that a requires clause which narrows the type 
should be respected to the same extent as an assertion.

----------------------------------------------------------------------

>Comment By: Daniel Bonniot (bonniot)
Date: 2005-02-12 18:58

Message:
Logged In: YES 
user_id=88952

OK. My point is that instead of defining

 int foo(Object arg) requires (arg instanceof Foo)

you could rather define

 int foo(Foo arg)

Then if you need to use foo (which has type Foo->int) where
an Object->int is needed, you can do it with a cast. It's
not less safe, since the requires clause is equivalent to a
cast, and it looks cleaner, since the definition of foo
itself is simpler, and you push the cast at the place where
something unsafe is really done.


----------------------------------------------------------------------

Comment By: mike.beckerle (mbeckerle)
Date: 2005-02-12 18:15

Message:
Logged In: YES 
user_id=1182016

I 'm sorry that I can't help further with this issue. I'm no
longer working on this particular experiemntal piece of
code, and I can't recall the context.

I think you can close the issue. Using the types as
aggressively as I was is something that people who study
lambda-calculus do, but nobody else. Everyone else would
create an object type. 




----------------------------------------------------------------------

Comment By: Daniel Bonniot (bonniot)
Date: 2005-02-11 15:36

Message:
Logged In: YES 
user_id=88952

Mike, once you have your heterogeneous list of functions,
how do you use it? How do you decide which function to apply
to a certain argument in a way that guarantees the function
will not fail?

----------------------------------------------------------------------

Comment By: mike.beckerle (mbeckerle)
Date: 2005-01-06 21:19

Message:
Logged In: YES 
user_id=1182016

ok. Thanks for the info. 

I am planning to try a base-class approach to my whole 
problem, and that may get around the whole thing. Instead of 
a list of peer functions with common signature it will be a list 
of objects where the list is a base-class type element.

I agree there's this issue with Nice which is whether to fix the 
number types of java so that Nice is easier to use (along the 
lines of the type relatioships in your last comments), or to be 
compatible with java, warts and all. 

Ditto for the fact that Strings aren't collections in java (even 
immutable), the equality semantics for strings is wrong, etc. 
etc. 

The best thing about Java is hotspot JVM with GC, and good 
high-level libraries like the J2EE stuff. The low-level libraries, 
and the language itself are quite flawed and worth departing 
from.



----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2005-01-06 20:56

Message:
Logged In: YES 
user_id=688815

I understand why you want to use that. But it's only needed 
because of a deeper problem.

The use of polymorpic list is problematic in every static type 
language and using a common supertype is the easiest way to 
do that.

The current handling of primitive type is preventing 
straightforward code in your example.

Nice does have autoboxing and goes a step further than Java 
autoboxing.
Nice merges the primitive types and the wrapper classes so 
the compiler chooses if you write int between int and Integer 
depending on the usage.

It might be usefull to give 'instanceof WrapperClass' a warning 
because the wrapper classes don't exist in Nice.

The problem with making primitives behave like objects is 
implementing instanceof and pattern matching, so that isn't 
possible atm.
Firstly the subtyping relations between the primitives and 
wrapper classes isn't the same, for example Integer doesn't 
extend Long.
Secondly the same value can be autoboxed in different 
wrappers, for example when a int value is a long value it 
might be boxed to a Long.
An implementation of 'x instanceof int' could look like:
(x instanceof Byte) || (x instanceof Short) || (x instanceof 
Integer) || ((x instanceof Long) && ((Long)x).longValue() >= 
Integer.MIN_VALUE && ((Long)x).longValue() <= 
Integer.MAX_VALUE)
So this is quite awkward.
Creating an alternative set of wrapper classes could work too 
but would reduce and complicate the interoperation of Nice 
and Java code.

I think handling of primitives as objects needs reconsideration.
I would prefer a more consistent language on this aspect but i 
doubt whether it's completely possible with reasonable 
performance and good Java interoperation.

----------------------------------------------------------------------

Comment By: mike.beckerle (mbeckerle)
Date: 2005-01-06 00:50

Message:
Logged In: YES 
user_id=1182016


I didn't provide enough code to motivate the example.

Here's my situation:

I have a list of functions

class MyFunctionList extends LinkedList<(Object -> Object)> 
{}


The actual functions are type specific, That is, some 
functions only work on Integers, others on Strings.

So, each function looks roughly like this:

Object myIntegerFunc(Object arg)
  requires (arg instanceof Integer)
{
.... code here should assume arg is an Integer....
}

Object myStringFunc(Object arg)
  requires (arg instanceof String)
{
...code here should assume arg is a string....
}

Allas, I can't use requires. I have to put asserts into the 
above. That's the bug I'm reporting.

Both the functions are put into a list

let MyFuncList myFnList = new MyFuncList([myIntegerFunc, 
myStringFunc]);

This also tells you why I'm using Integer. It's because I need 
polymorphic objects that can be String or Integer (or other 
things eventually)

This turns out to be a big pain in Nice (as it would be in Java) 
since support for non-primitive number types is so poor. btw 
I noticed that Java's new "autoboxing/unboxing" for numbers 
isn't there in Nice.






----------------------------------------------------------------------

Comment By: Arjan Boeijink (arjanb)
Date: 2005-01-05 23:11

Message:
Logged In: YES 
user_id=688815

This is not a bug I think.
All things that are expressable in the arguments types don't 
need to be in preconditions.
Why not write:
int foo(int arg) instead?

btw Integer is the java class and should usually not be used 
in Nice code.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112788&aid=1096722&group_id=12788


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click