light weight types

R

Roedy Green

Consider a program that uses a mixture of 10-character and 13-digit
ISBN numbers (International Standard Book Number). From Java's point
of view, they are all Strings.

It would be nice if there were some mechanism to label Strings with a
light-weight type, probably a purely compile-time concept, similar to
generics. You would then label some string vars as ISBN13 and some as
ISBN10, and similarly parameters to methods. Then the compiler could
detect an improper passing of in ISBN13 string to an ISBN10 parameter.

An extension of this idea is units of measure, so that you could not
pass a cm variable to an inch parameter (though possibly you could
with an automatic conversion applied).

Think how many times you have wondered if a variable is measured in
seconds, ms, or ns. Here would be a formal way to specify and check
your assumption was correct.

Going a step further, your type might have a associated assertion to
make sure the value were valid. Perhaps there would be a way to
insert that assertion at every assignment.
--
Roedy Green Canadian Mind Products
http://mindprod.com

When you are programming and you feel paralysis from overwhelm:
(o) Write down your worries in an electronic todo list, so you can temporarily stop thinking about them.
(o) Write smaller modules and classes so you don’t need to juggle many facts to complete the code.
(o) Do some necessary, but simple, clerical task.
(o) Solve some simple problem with at least some probability of being useful in the big solution. It will break the logjam.
~ Roedy
 
M

markspace

Roedy said:
It would be nice if there were some mechanism to label Strings with a
light-weight type, probably a purely compile-time concept,...

An extension of this idea is units of measure, so that you could not
pass a cm variable to an inch parameter (though possibly you could
with an automatic conversion applied).


While I understand what you're saying, I think just making wrapper
classes is correct, and pretty darn light-weight too. Once you make a
ISBN10 label, you have to verify that you only attach this label to
valid objects, and then you have to define any special operations that
work with this label, and then... you've got a class anyway.
 
A

alexandre_paterson

Consider a program that uses a mixture of 10-character and 13-digit
ISBN numbers (International Standard Book Number). From Java's point
of view, they are all Strings.

I kinda see what you mean but I'm puzzled by your "they're all
Strings".

Why would they be all Strings?

Why not use real OO abstraction for the ISBNs?

What about:

interface ISBN {

... getEAN();

... getCountryOrArea();

... isCheckDigitCorrect();

etc.

}

?

Say, here's a nice Douglas Cockford base 32 encoded product
key we're using for our software (fake number ;)

4BTZA0 - T85Q - 2HNSQ8 - MBX2 - 70PHVV - BSZD - QCN2D1

In our codebase we don't treat that as a String...
It's a ProductKey and our ProductKey abstraction
provides many things related to, well, product keys.
 
R

Roedy Green

Why not use real OO abstraction for the ISBNs?

In my particular case, that makes a lot of sense, instead of passing
around Strings, I need only pass ISBN objects around. If I need a
10-char, 13-char, 10-decorated, 13-decorated version, I decide at the
last minute with a get. It is also easier to maintain. If the HTML I
generate changes from 10 to 13, I change it in one place. I don't
have to modify the chain of parameter passings.
--
Roedy Green Canadian Mind Products
http://mindprod.com

When you are programming and you feel paralysis from overwhelm:
(o) Write down your worries in an electronic todo list, so you can temporarily stop thinking about them.
(o) Write smaller modules and classes so you don’t need to juggle many facts to complete the code.
(o) Do some necessary, but simple, clerical task.
(o) Solve some simple problem with at least some probability of being useful in the big solution. It will break the logjam.
~ Roedy
 
J

Jim

In my particular case, that makes a lot of sense, instead of passing
around Strings, I need only pass ISBN objects around. If I need a
10-char, 13-char, 10-decorated, 13-decorated version, I decide at the
last minute with a get. It is also easier to maintain. If the HTML I
generate changes from 10 to 13, I change it in one place. I don't
have to modify the chain of parameter passings.

Roedy, Sounds like Pascal Type declarations, which is one of the
things I really miss in Java.

Jim
 
K

Kevin McMurtrie

Tom Anderson said:
Gosling keeps talking about adding this to java.


If you want to be able to have arbitrary units which can be checked at
compile-time, sure, you need to add difficult stuff to the language. If
you can satisfy yourself with a fixed set of units, or runtime-only
checking, you can do it in java now.

tom

Hopefully nobody 'solves' this by adding Generics to Strings. Java's
syntax is already going off the deep end. (And yet the simple things
like unsigned math and arrays of contiguous Object data are dismissed as
not worth the effort.)
 
M

markspace

Michal said:
The ones I think are needed are changes extending the
type system so that more bugs can be eliminated statically


What sort of changes would you advocate?
 
A

Alessio Stalla

Both of those are real annoyances... I've got one more though, closures.  
Anonymous classes are ugly when unneeded.

The problem with closures is that there's not enough consensus on how
they should be done. The most popular proposal, "BGGA", has some
idiosyncracies that make it work in a subtly different way than how
closures work in most other languages that have them. I'd love to have
closures in Java, but you have to think very carefully before adding
something that big to a language.
 
J

Joshua Cranmer

1. Option types

It's already happening for Java 7--look under the heading "type
annotations."
2. First class type parameters ( "new T()" anybody? :) )

What would happen if T were an interface or abstract? Better yet, what
if it were a wildcard type parameter?
 
A

Alessio Stalla

Hmm... It is more like a wishlist:

1. Option types
Whatever the name of the feature - I'd like to be able to mark a variable as
not null (I would actually prefer to mark variables as nullable but that
would not be backwards compatible). And I don't think adnotations are
enough.

I don't like this. Marking a variable as not nullable may mean two
things (not necessarily mutually exclusive):

- that the variable is checked statically by the compiler to never
ever be assigned null, and the program does not compile if the
compiler cannot determine this. This would make the feature be not
very useful because most of the time it's not possible to determine
statically such a property of variables, especially when it would
matter most, i.e. when the value comes from an outside source.

- that every write access to the variable is checked at runtime and
throws an exception if the new value is null. This would have a
significant performance hit.
2. First class type parameters ( "new T()" anybody? :) )

Absolutely, and the ability of type parameters to constrain the
constructors the class must have, as IIRC .net does (given <T(Integer,
String)> you can create a new T(1, "hello"))
3. Metaclasses as described in the publication I gave link to would be useful

Metaclasses are cool, but they would have a huge impact on Java and
the whole JVM platform.
Just from the top of my head...

Type inference would be very cool too, and it could only impact the
compiler, while leaving the JVM and class file format completely
untouched.

Alessio
 
T

Tom Anderson

Fixed set of units is problematic because it is... fixed :)
Runtime-only checking is actually no checking at all (who cares if a bug
manifests itself in an IllegalArgumentException or otherwise?)

Because that's going to be a lot more obvious during testing than a value
being silently wrong.

tom
 
A

Arne Vajhøj

Joshua said:
What would happen if T were an interface or abstract? Better yet, what
if it were a wildcard type parameter?

Obviously it would need to be a restriction that T is known to
have a parameter less constructor.

It works in C#.

Arne
 
M

Mike Amling

Roedy said:
Consider a program that uses a mixture of 10-character and 13-digit
ISBN numbers (International Standard Book Number). From Java's point
of view, they are all Strings.

It would be nice if there were some mechanism to label Strings with a
light-weight type, probably a purely compile-time concept, similar to
generics. You would then label some string vars as ISBN13 and some as
ISBN10, and similarly parameters to methods. Then the compiler could
detect an improper passing of in ISBN13 string to an ISBN10 parameter.

You could define classes ISBN10 and ISBN13.
An extension of this idea is units of measure, so that you could not
pass a cm variable to an inch parameter (though possibly you could
with an automatic conversion applied).

Think how many times you have wondered if a variable is measured in
seconds, ms, or ns. Here would be a formal way to specify and check
your assumption was correct.

Going a step further, your type might have a associated assertion to
make sure the value were valid. Perhaps there would be a way to
insert that assertion at every assignment.

Surely someone somewhere must have something like this already, with
classes or interfaces for time, distance, mass, etc.

--Mike Amling
 
K

Kevin McMurtrie

"Kenneth P. Turvey said:
Both of those are real annoyances... I've got one more though, closures.
Anonymous classes are ugly when unneeded.

That too. MacOS 10.6 now uses them for lightweight parallel code
execution. Java has the Future and Callable classes but they're clumsy.
 
A

Alessio Stalla

See:http://nice.sourceforge.net/
for a quite handy solution.
The programmer is forced to check for null when assigning a value of
nullable expression to a not null variable.

Then it's the second case (runtime check), and it is even worse as the
runtime check is not generated by the compiler but has to be
explicitly written by the programmer. I think throwing
NullPointerException is the right thing in certain cases (although
often it is caused by a bug).
I don't think I like this one. It think it causes (compile time) errors to
appear in wrong places (too late). I see a variable type specification as a
programmer's expectation stated explicitly. If the expectation is not met
it should be signalled by the compiler in the right place.

Well I'd like type inference to be optional, not mandatory, so if you
like to state your expectation about the type of the variable, or you
want to use an interface even if the static type of the assigned
expression is a concrete class, you'd still be able to do that.
On the other hand, you could write var x = new HashMap<String,
List<MyThing>>() instead of
HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>>
() which imho would only make the code clearer.

Alessio
 
L

Lew

Alessio said:
Well I'd like type inference to be optional, not mandatory, so if you
like to state your expectation about the type of the variable, or you
want to use an interface even if the static type of the assigned
expression is a concrete class, you'd still be able to do that.
On the other hand, you could write var x = new HashMap<String,
List<MyThing>>() instead of
HashMap<String, List<MyThing>> x = new HashMap<String, List<MyThing>>
() which imho would only make the code clearer.

It does not make the code clearer, just shorter.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top