• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why length(), length, size differences?  RSS feed

 
Fred Wolf
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hola,

sorry .. the "Orthogonality Freak" again ... the (mock) exam builders tend to trick you by trying to get you to accept wrong syntax for any kind of "length" operations
So far I came across ..

Then you get presented with stuff like al.lenght and "Ha Ha Ha .. you're wrong .. see the API" (which contains thousands of methods .."

More or less three forms of syntax for more of less the same semantics - is there any "rationale" behind this or is it again - get yourself an Asperger diagnosis,
shut up and learn the phone directory ;-)?

Thanks

Fred
 
Paul Clapham
Sheriff
Posts: 22841
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just to address one thing: an ArrayList is a Collection (see the API documentation and you'll find that ArrayList implements Collection). Now, ArrayList has a size() method because Collection has a size() method. If it were otherwise, you'd be on here asking why Collection had a length() method, and saying that size() would be a much better name than length() would. And that would be right. Obviously a Collection has a size and not a length; and since an ArrayList is a Collection, it has a size too.
 
Fred Wolf
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank You.. this plus the fact that array are more like a primitive type is enough of a hint to remember ...
 
Paul Clapham
Sheriff
Posts: 22841
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Just like real languages (e.g. Latin), structures which look irregular are often based on different rules which make them regular in a different way.
 
Ivan Jozsef Balazs
Rancher
Posts: 999
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
As if the naming convention were that it is "length" when it is final, can not change, like the dimension of an array, or the number of the characters of an immutable String, and "size", when it can change, like the numer of the elements in a collection.
 
Fred Wolf
Greenhorn
Posts: 9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
for strings, StringBuilders length() is intuitively clear;
For array the omission of the brackets is somehow a bit bumnpy
For a Set size() would be intuitive - as the ArrayList is a Collection - then size() makes sense - but is not what spontaneusly comes to your mind for a Array .. List :-)
Anyway - I'll have to "learn it verbatim"
Thanks to you all
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe they are different because they were written by different people at different times. Maybe that is why you have length in one place and length() in another.
Maybe because there are old, traditional names for those actions going back to before Java®. Words like push pop and peek, which is what you do to stacks, or offer and poll (queues) and add or remove (lists and sets) are widely used, but with practice you will become familiar with them. I am afraid there is no substitute for lots of practice; you can't expect to learn them all quickly.
I am afraid you are going to have to learn you r way round the API documentation too. It isn't that difficult; there probably aren't even a million methods to search through. But you can start by going to String where you will find two links called “METHODS” near the top. Click that nearer the left, and you get to the method summary, and by scrolling down to L, you will find the length() method. Read what it says both there and when you click on length which takes you to a fuller explanation. Read what you can understand and ask about wht you can't understand.

Also: don't try to learn the documentation off by heart or memorise any of it. If you have to look the same thing up 10× an hour, look it up 10×.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Note that there are 2 very hard problems in software engineering: cache invalidation, naming things, and off-by-one errors.

Of these, naming things is the most difficult.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16060
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The API of Java's standard library is far from perfect. It's full of inconsistencies and there are lots of examples of inconsistent naming and poorly designed classes and interfaces. As Campbell says, because it was written by different people at different times.
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Jesper de Jong wrote:. . . inconsistent naming and poorly designed classes and interfaces. . . .
Some of them have been largely sorted out, for example by replacing Date/Calendar with LocalDate, etc., Some haven't. Joshua Bloch says somewhere (Effective Java 2/e page 86) that there are problems with the design of classes like Stack and Properties. I use stacks in Forth, so I think they have never really corrected Stack.
 
Stephan van Hulst
Saloon Keeper
Posts: 7993
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Well, just as how Date has been replaced by LocalDateTime, Stack has been replaced by Deque.
 
Campbell Ritchie
Marshal
Posts: 56598
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
But a deque isn't a stack and a stack isn't a deque. A basic stack has about three actions: push pop and peek. You might want isEmpty(), too. By using Deque, you get a stack which will accept elements at either end of it, which is different from the usual concept of a stack. If you only use stack operations, you can't add things at one end and take them off the other end, which is what you usually do with queues and deques.
It is possible to design an advanced stack with more operations; Forth stacks support about ten or twelve more. But none does anything to the bottom of the stack.
 
Tobias Bachert
Ranch Hand
Posts: 86
18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you use the Queue interface, you will have exactly these three basic methods (besides the methods of Collection), push=add/offer, peek=peek/element and pop=poll/remove. Overall a Queue created by Collections.asLifoQueue(new ArrayDeque<>()) is a significantly better stack implementation than new Stack<>().
 
Liutauras Vilda
Sheriff
Posts: 4928
334
BSD
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
For everybody's reference:
Java 8 API Docs wrote:Deques can also be used as LIFO (Last-In-First-Out) stacks. This interface should be used in preference to the legacy Stack class. When a deque is used as a stack, elements are pushed and popped from the beginning of the deque. Stack methods are precisely equivalent to Deque methods as indicated in the table below:

Comparison of Stack and Deque methods
Stack MethodEquivalent Deque Method
push(e)addFirst(e)
pop()removeFirst()
peek()peekFirst()

 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!