Hacker News Reader

Comment by guipsp | Hacker News Reader

You can lock on any object - if you dynamically create these locks, then you need to coordinate creation among threads.

They're saying that only the lock should need storage in the object header, everything else can be computed on the fly (obviously at a CPU cost rather than memory).

Equality is computed (and the default is trivial, it just compares addresses), hashcode is computed (and the default is trivial, it just returns the object's address), string conversion is computed (and the default is trivial, it just prints the class name and the hashcode IIRC).

I'm not sure you can just return the object address for hashcode, because with GC the object address can move right? So if you are using it for hashcode, you do need to persist it somewhere after it's called the first time.

Would an optional "Hashable" class interface be a good way to reduce the classes (and objects) that need to have a hash? Or is having a hash an unavoidable primitive feature?

Also, would an optional "Lockable" class interface be a good way to drastically reduce the classes (and objects) that need to maintain lock information?

I am religiously averse to unused but implemented "Positive-Cost Abstractions". I dream of a root class with no methods except "new", and instance methods delete() and isSelf(x).

Even "Polymorphism" could be an opt-in interface. Subclasses of non-polymorphic classes would inherit functionality (yay, reusability), but not be a subtype of their root class.

(With commutativity between subclassing & the polymorphic interface. I.e. If A is a non-polymorphic class, and Ap is a polymorphic version of class A, then all subclasses of Ap and all polymorphic subclasses of A, would be subtypes of Ap.)

> the default is trivial, it just returns the object's address

This was trivial a long time ago. Now, all Java GCs move objects in memory.

Reply on news.ycombinator.com