Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Inserting In a List

Reply
Thread Tools

Inserting In a List

 
 
Robert Klemme
Guest
Posts: n/a
 
      04-03-2013
On 03.04.2013 12:15, lipska the kat wrote:
> On 02/04/13 20:06, Robert Klemme wrote:
>> On 04/02/2013 04:08 PM, lipska the kat wrote:
>>
>>> Just as a matter of interest what's with all the finals
>>>
>>> particularly
>>>
>>> for (final File name : folder.listFiles())

>
> [snip]
>
>> I believe in using "final" pretty often as it will immediately indicate
>> which local variables are constant for a method call and which are
>> modified all the time. Plus, with "final" you can easier catch errors
>> in control flow:
>>
>> final String x;
>>
>> if ( someCondition() ) {
>> x = y.toString();
>> }
>> else {
>> if ( someOtherCondition() ) {
>> x = "foo";
>> }
>> // forgot the else branch here
>> x = "bar";
>> }
>>
>> System.out.println("We got " + x);
>>
>> Generally I find "finally" quite useful - apparently significantly more
>> useful than you do.

>
> Well I'm not sure that using a storage class to help you write a
> conditional statement is 'good programming style' but hey ho, different
> strokes for different folks


I am not sure what you mean by that. Can you elaborate? Where's the
storage class in the example above?

> Anyway, the usability of final depends on your point of view I suppose.


We can certainly agree on *that*.

> If for some reason I find myself using 'final' all over the place then I
> would have to ask myself if my abstraction was coherent. If one has
> something, or in fact a number of somethings that need 'protecting' in
> this way then surely it is better to wrap them up in a component and
> control access by virtue of the public interface of that component.


It probably depends. Sometimes you want to hold on to something because
obtaining it is expensive or the accessor might return a changed version
during subsequent calls but you want to be sure to retain a specific
status. In those cases I would not think that wrapping it up
necessarily helps because the data may actually have been wrapped
already. It feels a bit over the top introducing another layer just to
avoid a local variable with "final".

> It's more OO, makes for cleaner code and of course provides opportunity
> for the holy grail of OO 're-usability'


Maybe I could better see (and agree) if you provide a specific example
of what you mean here.

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
 
 
 
Joerg Meier
Guest
Posts: n/a
 
      04-03-2013
On Wed, 03 Apr 2013 19:51:05 +0100, lipska the kat wrote:

> [...] When I see the
> modifier final it says something to me, it says, this value is not
> modifiable ('scuse the pun).


Then you need to read a Java beginner tutorial

"final" makes a variable or field impossible to reassign. It says
absolutely nothing at all about whether or not that variables is
modifiable. What you are thinking of is immutability, something that is not
formalized in Java. In Java, having final mutable fields is perfectly
legitimate.

I know you know that, of course, I'm just saying, that's not really a
sensible way to look at final imo.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
 
 
 
Robert Klemme
Guest
Posts: n/a
 
      04-03-2013
On 03.04.2013 20:51, lipska the kat wrote:
> On 03/04/13 18:08, Robert Klemme wrote:


>> I am not sure what you mean by that. Can you elaborate? Where's the
>> storage class in the example above?

>
> final, although it's not is it, at least it's not Java terminology,
> apologies, I should have said 'modifier'. I'll restate.


Ah, OK, I see. Thanks!

> Well I'm not sure that using a modifier to help you write a
> conditional statement is 'good programming style'. When I see the
> modifier final it says something to me, it says, this value is not
> modifiable ('scuse the pun).


Sometimes you need nested conditions as shown and with a blank final you
can ensure that the variable is assigned exactly once on every possible
path. I find that useful.

> Is it improving the clarity of your code to
> use final for it's side effect, that is the side effect of causing the
> compiler to barf because a final variable may already have been
> initialized. I'm not sure about that.


That's not a side effect - it is _the_ effect of "final" modifier for
variables. "final" ensures a variable is assigned to at most once:

http://docs.oracle.com/javase/specs/...tml#jls-4.12.4

There is no other effect - final is all about assignment. This is true
for local variables - it's different with field which get assigned
compile time constants.

I'd say, "final" is probably even more useful for fields because it
ensures that a field is initialized in every constructor path - you
cannot forget it.

http://docs.oracle.com/javase/specs/...ml#jls-8.3.1.2

> For a single local variable I'd probably agree, in fact in general I
> would agree but that wasn't my initial point really, in the code that
> kicked off this sub thread there was more than one final variable, in
> fact there were several in close proximity, I was initially questioning
> the clarity of this for a new user. However then I opened my mouth and
> put my foot in it and said ...




>> Maybe I could better see (and agree) if you provide a specific example
>> of what you mean here.

>
> I think you probably know what I mean and any off the cuff example will
> be contrived to the point irrelevance, so, leave it with me and I'll see
> if I can come up with a simple self contained example.


Thank you!

Kind regards

robert

--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      04-03-2013
On 04/03/2013 10:26 AM, Joerg Meier wrote:
> On Wed, 03 Apr 2013 05:45:46 -0300, Arved Sandstrom wrote:
>
>> On 04/02/2013 09:04 PM, Joerg Meier wrote:
>>> Java doesn't have ArrayMaps.

>> [SNIP]

>
>> Well, Java actually does have ArrayMaps, if one is willing to include
>> published APIs other than those of the JDK.

>
> If one is willing to do that, the expression "Java has" or "Java doesn't
> have" becomes effictively meaningless.
>
> For example, would you consider the following statements to be true ?
>
> Java has a 'val' data type.
> Java has an OpenGL 3D engine.
> Java has automatic getter and setter generation.
> Java has voice recognition.
> Java has function pointers.
> Java has delegates.
>
> I think most people would say those, as well as "Java has ArrayMaps", are
> wrong. There is relatively little point to asking if a language the size
> and popularity of Java has something 3rd party created.
>
> In other words: no, when I say "Java doesn't have xxx", I don't count third
> party libraries, and I have trouble believing most other people would.
>
> Liebe Gruesse,
> Joerg
>

If we're going to be pedantic I might as well add that I wouldn't myself
say that Java has ArrayLists or HashMaps either. I consider "Java" to be
the language. If we're going to talk official libraries you'd have to
refer to a specific version of J2SE/Java SE or J2EE/Java EE, for example.

Having said that, I think the pragmatic question would be (or would have
been), are there reliable libraries available for a Java programmer to
do X? In many cases, both now and historically, if one were to adopt
your narrower definition, one would have to admit that X cannot be
easily done with just the Java language and official platform
APIs/implementations, not without a great deal of coding, whereas in
reality people would be availing themselves of well-known 3rd party
libraries to do just that.

AHS
 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-03-2013
On 4/3/2013 12:01 PM, Joerg Meier wrote:

> "final" makes a variable or field impossible to reassign. It says
> absolutely nothing at all about whether or not that variables is
> modifiable. What you are thinking of is immutability, something that is not
> formalized in Java.


Well, immutability is formalized in the JLS, and it's pretty important:

"final fields also allow programmers to implement thread-safe immutable
objects without synchronization." etc.

<http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>

You might be referring to something else, but what you wrote there is
kind of misleading, at least.


 
Reply With Quote
 
Arne Vajh?j
Guest
Posts: n/a
 
      04-03-2013
On 4/3/2013 5:15 PM, markspace wrote:
> On 4/3/2013 12:01 PM, Joerg Meier wrote:
>
>> "final" makes a variable or field impossible to reassign. It says
>> absolutely nothing at all about whether or not that variables is
>> modifiable. What you are thinking of is immutability, something that
>> is not
>> formalized in Java.

>
> Well, immutability is formalized in the JLS, and it's pretty important:
>
> "final fields also allow programmers to implement thread-safe immutable
> objects without synchronization." etc.
>
> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>
>
> You might be referring to something else, but what you wrote there is
> kind of misleading, at least.


????

The text you quote do not define immutable neither formal nor informal.

It refer to the concept.

If immutable is defined formally somewhere in the JLS it must be
somewhere else.

Until we have a ref, then I can't see anything misleading.

Arne



 
Reply With Quote
 
markspace
Guest
Posts: n/a
 
      04-03-2013
On 4/3/2013 3:22 PM, Arne Vajh?j wrote:

> The text you quote do not define immutable neither formal nor informal.
>
> It refer to the concept.
>
> If immutable is defined formally somewhere in the JLS it must be
> somewhere else.
>
> Until we have a ref, then I can't see anything misleading.



Are you serious, Arne? Did you read the section I linked to? I didn't
quote the whole thing, it would be immense. I just quoted one line to
show that the section did talk about immutability, not to definitively
establish all the ins-and-outs of immutability in the JLS. There's no
point in me copying what you can read yourself.

Honestly I'm shocked at your response and I think you're missing the
point by a wide margin. Are you trying to tell me that final fields are
not involved in immutability in Java?


 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-03-2013
On Wed, 03 Apr 2013 14:15:56 -0700, markspace wrote:

> On 4/3/2013 12:01 PM, Joerg Meier wrote:
>> "final" makes a variable or field impossible to reassign. It says
>> absolutely nothing at all about whether or not that variables is
>> modifiable. What you are thinking of is immutability, something that is not
>> formalized in Java.

> Well, immutability is formalized in the JLS, and it's pretty important:


> "final fields also allow programmers to implement thread-safe immutable
> objects without synchronization." etc.


> <http://docs.oracle.com/javase/specs/jls/se7/html/jls-17.html#jls-17.5>


> You might be referring to something else, but what you wrote there is
> kind of misleading, at least.


You display an honestly shocking and disturbing misunderstanding here. I
can only assume that this is some sort of temporary brain fart on your part
or bad communication between us. Making an object reference final does not
make the object immutable, and I have trouble believing you really think so
yourself.

Think about this piece of code:

final Point p = new Point(0, 0);
p.move(1, 1);

Are you really trying to say that you believe that the final keyword has
made p immutable, and that the call to p.move will fail to mut..ate ? p,
and that a subsequent call to p.getX() will return 0 ? Because if yes, then
you are simply wrong, and if no, then p is not immutable.

What the above quote means (and says) is that by USING final in the MAKING
of an object (as in writing a class), you can make an immutable object:

public class A {
final int b = 123;
}

A a = new A(); will now produce an immutable object a.

In fact it is a very popular (if not the most popular) way to deal with
synchronization to simply make as much as you can immutable, as that frees
you of a majority of synchronization concerns and issues.

But of course, again, you cannot make an mutable OBJECT immutable simply by
creating a reference to it that is decorated with final.

Basically, it's an issue about outside or inside: using final inside an
object on its fields can make that object immutable (assuming all state is
covered with finals), but just because you have a final reference to an
object does not change whether the object is modifiable or not.

Again, I'm pretty certain that you already know all of the above and we are
just having a communication breakdown.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-03-2013
On Wed, 03 Apr 2013 18:09:36 -0300, Arved Sandstrom wrote:

> If we're going to be pedantic I might as well add that I wouldn't myself
> say that Java has ArrayLists or HashMaps either. I consider "Java" to be
> the language. If we're going to talk official libraries you'd have to
> refer to a specific version of J2SE/Java SE or J2EE/Java EE, for example.


You can feel free to say whatever you want, but lets be realistic: the
majority of people will say "Java has" for stuff in the JCL, and "Java
doesn't have" for stuff not in the JCL. And I am 99% certain that if I had
asked you any of the examples above, you would have said "No, Java doesn't
have a val data type", and you would have says "Yes, Java has a hash map,
it's java.util.HashMap".

You can be pedantic all you want, but I would argue that "stuff in the JCL"
is the definition used by the vast majority of people and really the only
one that makes much sense.

> Having said that, I think the pragmatic question would be (or would have
> been), are there reliable libraries available for a Java programmer to
> do X? In many cases, both now and historically, if one were to adopt
> your narrower definition, one would have to admit that X cannot be
> easily done with just the Java language and official platform
> APIs/implementations, not without a great deal of coding, whereas in
> reality people would be availing themselves of well-known 3rd party
> libraries to do just that.


If one was asking about libraries, one would likely ask that, and not
whether Java has it. I can only repeat what I said above.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
Joerg Meier
Guest
Posts: n/a
 
      04-03-2013
On Wed, 3 Apr 2013 22:43:51 +0000 (UTC), Martin Gregorie wrote:

> On Wed, 03 Apr 2013 02:04:19 +0200, Joerg Meier wrote:
>> On Tue, 2 Apr 2013 22:52:20 +0000 (UTC), Martin Gregorie wrote:
>>> On Tue, 02 Apr 2013 18:22:55 -0400, Eric Sosman wrote:
>>>> On 4/2/2013 5:06 PM, Martin Gregorie wrote:
>>>>>[...]
>>>>> Its also not clear to me whether the OP is expecting some form of
>>>>> sorted list of filenames. If he is expecting that, it would be best
>>>>> to use a TreeMap<String> rather than an ArrayList<String> to store
>>>>> the filenames.
>>>> Is there a reason to prefer TreeMap (or other SortedMap) over
>>>> accumulate-disordered-and-sort-afterward?
>>> I think so, yes, because none of File's list() and listFiles() methods
>>> guarantee the order of the returned files. By using TreeMap or
>>> equivalent the OP gets the sort for free, should it be required.

>> For free ?

> I meant in terms of coding effort.


In terms of coding effort, it's one single line.

>> The cost is just distributed amongst the insert calls, and is
>> likely considerably higher than with an unsorted list that has a single
>> sort call once it is filled.

> Not necessarily so (see above) and that's why I specified a TreeMap
> rather than any other type of ordered map because of the relative drop in
> access costs as the collection size increases.


A TreeMap has a higher access cost than an ArrayList. It's O(log(n)) for
both get and put, whereas ArrayList's is O(1).

>> SortedMaps are for things that need sorting
>> accessible before all elements are inserted

> And isn't the case with the TreeMap either - red-black binary trees have
> rather nice characteristics there.


Which are nevertheless still only in the best case scenario as good as the
alternative, and never better.

>> Java doesn't have ArrayMaps.

> Yeah, I meant ArrayList and should have been obvious from the context
> provided by the OP.


Not really. Since you want access by key, it makes no sense to use an
ArrayList at all. But I suppose your original point, then, was correct: a
TreeMap would indeed be superiour to storing logical map data in an
ArrayList - I'm not even sure how you would fit both key and value into an
ArrayList. Was your alternative to using a Map to make a patchwork Entry
class to put keys and values in, and then make an ArrayList of those ?

Because if it was, I can think of plenty more scenarios that would be worse
than storing things in a TreeMap. Storing them in a String, for example.
But just because Strings suck to store map data in doesn't mean everyone
who wants to store map data should therefore use a TreeMap.

Liebe Gruesse,
Joerg

--
Ich lese meine Emails nicht, replies to Email bleiben also leider
ungelesen.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Inserting into DB table with date from Generic List =?Utf-8?B?U3Jpbmk=?= ASP .Net 0 11-07-2006 04:33 AM
inserting into a list John Salerno Python 15 03-08-2006 06:02 AM
Linked list inserting items from two different funcion Kay C++ 1 09-03-2004 03:48 PM
Urgent:Inserting records from datagrid through drop down list Muhammad Usman ASP .Net 1 10-16-2003 01:39 PM
Inserting an empty element in a list (STL) Massimiliano Alberti C++ 3 09-24-2003 05:48 PM



Advertisments