Your code, as posted, doesn't compile because there is no definition for the Address
type. However, given the code for nextFreeAddress
in the alloc()
method, it's pretty obvious that Address
can only be type Int
, so that's easy to fix.
Also, HeapImpl
is private
to ... what? A surrounding object
I assume, but that's also missing from the posted code so it's a bit unclear. You say you "would like to hide implementation details," which is a good thing, but I don't know that a private implementation class is significantly more hidden than having private members of a public class. Is the implementation class separate because you envision multiple different implementations available to the end user?
It's a bit unusual to have a factory method that takes no parameters except for a type parameter. It wouldn't be difficult to enhance the "constructor" to take optional initial values.
object Heap {
def apply[T](ts:T*): Heap[T] = HeapImpl(ts.indices.map(x => x -> ts(x)).toMap)
}
Then you can have it both ways:
Heap[Char]() //res0: Heap[Char] = HeapImpl(Map())
Heap(3L, 5L, 12L, 2L) //res1: Heap[Long] = HeapImpl(Map(0 -> 3, 1 -> 5, 2 -> 12, 3 -> 2))
(Notice that the REPL has leaked a bit of your implementation detail.)
At first I was confused by the term Heap
. Then I re-read the posting and realized that this isn't a heap data structure but is, instead, a chunk of memory for dynamic allocation and requiring memory management.
But your code doesn't actually do any of the things that makes a real heap challenging/interesting: dynamic allocation for heterogeneous data, handle fragmentation, etc. It sort of pretends to be a heap, but not very convincingly (your alloc()
doesn't really act like malloc()
, calloc()
, or realloc()
). It's just a thin wrapper around a highly restricted associative array.
So, while I find little to fault in the code, I can't see where isit serves much purpose.
Your code, as posted, doesn't compile because there is no definition for the Address
type. However, given the code for nextFreeAddress
in the alloc()
method, it's pretty obvious that Address
can only be type Int
, so that's easy to fix.
Also, HeapImpl
is private
to ... what? A surrounding object
I assume, but that's also missing from the posted code so it's a bit unclear. You say you "would like to hide implementation details," which is a good thing, but I don't know that a private implementation class is significantly more hidden than having private members of a public class. Is the implementation class separate because you envision multiple different implementations available to the end user?
It's a bit unusual to have a factory method that takes no parameters except for a type parameter. It wouldn't be difficult to enhance the "constructor" to take optional initial values.
object Heap {
def apply[T](ts:T*): Heap[T] = HeapImpl(ts.indices.map(x => x -> ts(x)).toMap)
}
Then you can have it both ways:
Heap[Char]() //res0: Heap[Char] = HeapImpl(Map())
Heap(3L, 5L, 12L, 2L) //res1: Heap[Long] = HeapImpl(Map(0 -> 3, 1 -> 5, 2 -> 12, 3 -> 2))
(Notice that the REPL has leaked a bit of your implementation detail.)
At first I was confused by the term Heap
. Then I re-read the posting and realized that this isn't a heap data structure but is, instead, a chunk of memory for dynamic allocation and requiring memory management.
But your code doesn't actually do any of the things that makes a real heap challenging/interesting: dynamic allocation for heterogeneous data, handle fragmentation, etc. It sort of pretends to be a heap, but not very convincingly (your alloc()
doesn't really act like malloc()
, calloc()
, or realloc()
). It's just a thin wrapper around a highly restricted associative array.
So, while I find little to fault in the code, I can't see where is serves much purpose.
Your code, as posted, doesn't compile because there is no definition for the Address
type. However, given the code for nextFreeAddress
in the alloc()
method, it's pretty obvious that Address
can only be type Int
, so that's easy to fix.
Also, HeapImpl
is private
to ... what? A surrounding object
I assume, but that's also missing from the posted code so it's a bit unclear. You say you "would like to hide implementation details," which is a good thing, but I don't know that a private implementation class is significantly more hidden than having private members of a public class. Is the implementation class separate because you envision multiple different implementations available to the end user?
It's a bit unusual to have a factory method that takes no parameters except for a type parameter. It wouldn't be difficult to enhance the "constructor" to take optional initial values.
object Heap {
def apply[T](ts:T*): Heap[T] = HeapImpl(ts.indices.map(x => x -> ts(x)).toMap)
}
Then you can have it both ways:
Heap[Char]() //res0: Heap[Char] = HeapImpl(Map())
Heap(3L, 5L, 12L, 2L) //res1: Heap[Long] = HeapImpl(Map(0 -> 3, 1 -> 5, 2 -> 12, 3 -> 2))
(Notice that the REPL has leaked a bit of your implementation detail.)
At first I was confused by the term Heap
. Then I re-read the posting and realized that this isn't a heap data structure but is, instead, a chunk of memory for dynamic allocation and requiring memory management.
But your code doesn't actually do any of the things that makes a real heap challenging/interesting: dynamic allocation for heterogeneous data, handle fragmentation, etc. It sort of pretends to be a heap, but not very convincingly (your alloc()
doesn't really act like malloc()
, calloc()
, or realloc()
). It's just a thin wrapper around a highly restricted associative array.
So, while I find little to fault in the code, I can't see where it serves much purpose.
Your code, as posted, doesn't compile because there is no definition for the Address
type. However, given the code for nextFreeAddress
in the alloc()
method, it's pretty obvious that Address
can only be type Int
, so that's easy to fix.
Also, HeapImpl
is private
to ... what? A surrounding object
I assume, but that's also missing from the posted code so it's a bit unclear. You say you "would like to hide implementation details," which is a good thing, but I don't know that a private implementation class is significantly more hidden than having private members of a public class. Is the implementation class separate because you envision multiple different implementations available to the end user?
It's a bit unusual to have a factory method that takes no parameters except for a type parameter. It wouldn't be difficult to enhance the "constructor" to take optional initial values.
object Heap {
def apply[T](ts:T*): Heap[T] = HeapImpl(ts.indices.map(x => x -> ts(x)).toMap)
}
Then you can have it both ways:
Heap[Char]() //res0: Heap[Char] = HeapImpl(Map())
Heap(3L, 5L, 12L, 2L) //res1: Heap[Long] = HeapImpl(Map(0 -> 3, 1 -> 5, 2 -> 12, 3 -> 2))
(Notice that the REPL has leaked a bit of your implementation detail.)
At first I was confused by the term Heap
. Then I re-read the posting and realized that this isn't a heap data structure but is, instead, a chunk of memory for dynamic allocation and requiring memory management.
But your code doesn't actually do any of the things that makes a real heap challenging/interesting: dynamic allocation for heterogeneous data, handle fragmentation, etc. It sort of pretends to be a heap, but not very convincingly (your alloc()
doesn't really act like malloc()
, calloc()
, or realloc()
). It's just a thin wrapper around a highly restricted associative array.
So, while I find little to fault in the code, I can't see where is serves much purpose.