Mansukhdeep Thind wrote:I have improved it a bit. See the get method now:
Concurrent modification is when more than one thread is trying to access my custom ArrayList at same time. Correct?
Are you hinting that I should make my class thread safe? I could not fully grasp this point.
What is meant by parametrization of a class?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
There is a much simpler way to implement that method, without double return or anything.Mansukhdeep Thind wrote: . . .
Is this what you were expecting it to look like? . . .
Yes.. . .
a) size() : returns the size of the current list.
b) add(E) : adds an element to the end of the list (already implemented)
c) add(int,E) : adds an element at a specified position in the custom list
d) get(int) :returns the element at the specified position (already implemented)
e) set(int, E) : Replaces the element at the specified position with the one passed.
f) remove(int) : removes the element specified int value
Is that correct Ritchie?
No. Concurrent modification is when you structurally alter the collection while there is an Iterator extant. Read the Iterator documentation.. . . Concurrent modification is when more than one thread is trying to access my custom ArrayList at same time. Correct? . . .
Winston has already answered that.. . . What is meant by parametrization of a class?
Don’t call your field nextIndex. That field represents how many elements there are in the list, so it needs a different name. I would also give a different name, maybe values, to the array. I suggest you start by adding another constructor:-Now work out how to implement the no‑arguments constructor.. . . So, you want me to remove the initialSize field and directly hard code the size inside the constructor. Something like:
Correct?
~ Mansukh
Mansukhdeep Thind wrote:But then it warns of "unchecked type casting". That in turn throws class cast exception at run-time because an Object cannot be cast to a String/Integer etc. What to do? How do I go about parameterizing my class?
a) I have implemented the no-argument constructor as above. It constructs a default array of size 10. Is it OK? Or were you expecting something else?
b) There are compile time warnings at 3 places saying "Unchecked type casting". (line numbers 22,33 and 42) Is that OK? How to manage those?
c) I am unable to print out the added elements using a simple for lop now. Line 154 throws ClassCastException. This is happening because Object is not a T(Integer in this case) I believe there is something wrong in my parametrization of the class. Please give clue as to what it is.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Winston Gutkowski wrote:2. Use Array.newInstance() to create your array and cast that. Unfortunately, you then need to provide a Class, object or array of the correct type to get the component type...
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
You have two choices:
1. Use an Object[] internally and cast elements when you return them (eg, for get(int)) - I think this is what ArrayList does.
2. Use Array.newInstance() to create your array and cast that. Unfortunately, you then need to provide a Class, object or array of the correct type to get the component type. There might also be a way to do it from the lists's own Type, but I don't know how.
It is 10.Seems reasonable. I think ArrayList uses either 10 or 16. I forget.
~ Mansukh
Mansukhdeep Thind wrote:Let me know if I have missed some finer point.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Done.1. If values is an Object[], there's no need for growArray() to return a T[].
Roger that. Done.2. Your size() method doesn't really need to go through the array (although there's nothing logically wrong with it). Why not just maintain a size field?
3. Your remove() method doesn't work like List's. There's nothing particularly wrong with this, but you should document that your List can contain "holes".
You are correct Winston. The for-each construct is currently returning only the first non-null consecutive elements in the list. If there is a null, it assumes there is no other element. I will have to change the iterator logic to accommodate for such a case.You may also find that it makes your Iterator (and particularly ListIterator) logic more complex - unless you're happy for them to return null elements - although, as I say, there's nothing particularly "wrong" with what you're doing.
~ Mansukh
Winston Gutkowski wrote:You may also find that it makes your Iterator (and particularly ListIterator) logic more complex - unless you're happy for them to return null elements
Mansukhdeep Thind wrote:
@ Ritchie : Waiting for you to pitch in and tell me which interface to implement next.
By this time perhaps you've had enough guidance through the process of doing one little piece at a time that you could decide for yourself which piece to do next?
~ Mansukh
Mansukhdeep Thind wrote:
By this time perhaps you've had enough guidance through the process of doing one little piece at a time that you could decide for yourself which piece to do next?
There are 3 left. RandomAccess, Serializable and List. RandomAccess is a marker interface. So is Serializable. How to implement those? Do I just declare these along with class declaration?
For Serializable, all your non-static fields must be primitives or references to types that are themselves Serializable, or else they must be declared transient and you'll reset their values explicitly on deserialization. Note that you can't control what types somebody adds to the list. If they add something non-serializable, that breaks serialization, but that's their fault and their problem. It's expected that a Java programmer using serialization will know that.
For RandomAccess, your list has to provide efficient access to an element at an arbitrary index. (Check the docs. It may even specifically require O(1) access. I'm not sure.) If you've written your class correctly, such that it uses the array index to access an element for a requested index, rather than iterating to it, then you meet the requirement. Note that if you allow holes in your list, such that you have to iterate past them to get to the next element, then you do not meet the requirements for RandomAccess.
~ Mansukh
Damn! sorry.Mansukhdeep Thind wrote:The following syntax is incorrect. Java does not allow us to write :
It has to be sure what "T" is. So, should I do like:
. . .
You have a serious potential error in line 74.
~ Mansukh
Campbell Ritchie wrote:Imagine you have a 16‑element array, all full (size == 16), and you attempt to add an element at position 11.
~ Mansukh
Mansukhdeep Thind wrote: . . . . . .
Try again.Earlier, I wrote: Imagine you have a 16‑element array, all full (size == 16), and you attempt to add an element at position 11.
~ Mansukh
Oh yes it will!Mansukhdeep Thind wrote:This scenario will not arise. . . .
~ Mansukh
No, you haven’t. I have tried it. I can add 10 items and have it print size = 9. I can add 31 items to it and have it show size = 0. I can add 31 items and get this:-Mansukhdeep Thind wrote: . . .
I have tested it thoroughly. . . .
$ java test.CustomArrayList
Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
at test.CustomArrayList.growArray(CustomArrayList.java:47)
at test.CustomArrayList.add(CustomArrayList.java:86)
at test.CustomArrayList.main(CustomArrayList.java:164)
~ Mansukh
It took less than two minutes and three keystrokes in your main method to get:-Earlier, I wrote:I bet I can break that list in under 5 minutes.
. . .
The code you have written for that method looks as though you are guessing. If you sat down with paper and pencil and actually designed that method, it would shrink to half its current size, and spoil my fun getting errors and Exceptions out of that class.java test.CustomArrayList
Size of list is 32
Capacity of list is 10
~ Mansukh
Campbell Ritchie wrote:That is the nice thing about object‑oriented programming. You can change one method without upsetting the rest of your class.
~ Mansukh
~ Mansukh
Campbell Ritchie wrote:What should take at least 5 minutes
~ Mansukh
Mansukhdeep Thind wrote:What is the difference between object oriented approach to programming and procedural programming.
Why can't I do this in procedural programming?
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
That is beccause I spelt is wronlgy. Sorry . It should have readMansukhdeep Thind wrote:
Campbell Ritchie wrote:What should take at least 5 minutes
Couldn't understand this remark..![]()
That should take at least 5 minutes
~ Mansukh
Change line no 155 to read myList.add(23, 35);Mansukhdeep Thind wrote:Here you go forum leader Campbell Ritchie, the final code:
Have your 5 minutes of fun breaking it.![]()
Campbell Ritchie wrote: Start by adding documentation comments to every method. For those methods which have an index position say the index must not be less than 0 and must be less than the current size. Once you have said that, you are entitled to throw Exceptions if the wrong index is given. Then you can say I ought not to try using 23 as an index. Then getting an Exception from myList.add(23, 35); no longer constitutes breaking the class.
Campbell Ritchie wrote: Write down carefully the structure of your list at the end of the main method (or better still, give it a toString() method and print it out). Print size elements of the array, not up to length. Call remover(4), and repeat the procedure. What has happened to the last element? Don’t give it a boolean return type.
Please check very carefully under which circumstance you need to enlarge the List, particularly in the add(int, T) method. The circumstances are really simple.
~ Mansukh
Change that to read @throws IndexOutOfBoundsException if index < 0 or index > current size.Mansukhdeep Thind wrote: . . . /**
* @throws exception - {@link ArrayIndexOutOfBoundsException}
*/ . . .
Campbell Ritchie wrote:And there is more to come.
"Leadership is nature's way of removing morons from the productive flow" - Dogbert
Articles by Winston can be found here
Or we might never have existed at all. Freaky. So we should cherish everything. Even this tiny ad:
The Low Tech Laboratory Movie Kickstarter is LIVE NOW!
https://www.kickstarter.com/projects/paulwheaton/low-tech
|