• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

final array

 
Ranch Hand
Posts: 216
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hey sir what is procedure to make an array element final
like if i make like
final int a=90;
a++//wrong
but if i make like
final int arr[2]={1,2};
arr[0]++// working why?
 
Ranch Hand
Posts: 2412
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Remember that arrays are objects and you what you declare as final is the reference to the array. Declaring an array reference final simply means that that array reference cannot be used to refer to a different array. It does not mean that the elements in the array are final.
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You can use a Collections.unmodifiableList() to mimic this functionality in a List.
[ April 01, 2006: Message edited by: Garrett Rowe ]
 
Sheriff
Posts: 11343
Mac Safari Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Garrett Rowe:
You can use a Collections.unmodifiableList() to mimic this functionality in a List.


Careful...

This means only that the List elements (references) cannot be modified. But you can still modify the objects that are referenced by an unmodifiable List.
 
Garrett Rowe
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Careful...

This means only that the List elements (references) cannot be modified. But you can still modify the objects that are referenced by an unmodifiable List.



Point condeded, however for immutable objects like Integers it is an option.
[ April 01, 2006: Message edited by: Garrett Rowe ]
 
Ranch Hand
Posts: 1608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Arrays are intrinsically mutable. You cannot detach the notion of mutability from an array, however, you can abandon arrays with minimal effort. The simplest way to do that is with an interface declaration:

...so long as you omit the "set" operation from the contract (which exists only to have an observable side-effect on the "get" operation - which is impure), you now have an immutable array. You could of course, write E such that it is mutable, however, I have ignored that for now.

The problem you are observing - and you are certainly not the first by a long shot - is what I have called "violation of perfect symbiosis of contractual operation", which is a side-effect that is forever tied to the notion of static contract inheritance (and OO as we know it). Simply, but not accurately, Java declares three operations that are symbiotic (forever in existence with each other), however, you have come up with a legitimate use case where you wish to remove one of those operations (the "set"). This is what "design patterns" are often used for - for example, "wrapping" types with less contract. Ultimately, they are workarounds to a language defect. In fact, if you manage to perform the required mindshift (the hard bit), you can observe that some extraordinary amount (99.9%?) of software development with Java is working around its shortcomings, which begs the question, "what are the consequences if these shortcomings were to be eliminated?".

ContractualJ mandates only one operation per interface (still not optimal ala static contract inheritance) and introduces the Sequence interface which attempts a minimal impact on clients for coming up with legitimate use cases that force a work around to static contract inheritance. That is, you can abandon arrays with a dependency on ContractualJ - a trade off that I often opt for in production.

Hope that makes some sense, even if just a bit
reply
    Bookmark Topic Watch Topic
  • New Topic