Please Unsubscribe me i am stick of this group
From: "Miguel" <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [Jmol-developers] PropertyManager feedback
Date: Tue, 14 Feb 2006 12:33:48 -0500 (EST)
> >>This type of comparison works *only* if returnType is an 'interned'
> >>string. An 'interned' string is guaranteed to be from a special string
> >>pool, so when comparing interned strings you can just compare the object
> >>pointers without looking at the string contents.
> >>
> >>
> >>
> > Are you saying that exact comparison, of a varible with a static string,
> > could be prone to this problem, or only when two variable strings are
> > involved?
>
>Not sure what you mean by 'variable strings'.
>
>Let's try this oversimplified explanation ...
>
>* Objects are pointers.
>
>* A String is a pointer to a variable-length sequence of unicode characters.
>
>* When you compare 'stringA == stringB' then you are comparing the values
>of the pointers themselves. This comparison of pointers can be done
>inline.
>
>* When you compare 'stringA.equals(stringB)' then you are comparing the
>sequences of unicode chars. This comparison generally requires function
>call overhead.
>
>* you can take an arbitrary string and 'intern' it ... stringA.intern()
>returns a reference to the interned string that is .equals(stringA)
>
>* an interned string is a reference (pointer) to a unique string in the
>intern pool.
>
>* Basically, all the interned strings get thrown into a hash table.
>
>* Given a source string, the intern method looks it up in the hash table.
>If not found, then the source string gets added to the hash table. The
>interned version of the string in the hash table now gets returned.
>
>* all string constants are guaranteed to be interned ... including string
>constants from different compilation units (classes).
>
>
> >>* I expect the number of properties to grow to at least one hundred.
> >>Therefore, over time we will evolve some clean mechanism to dispatch
> >> based
> >>upon propertyName.
> >>
> >>
> > whew. You think?
>
>Yes, I think so.
>
> > Can you save method pointers in properties, then just
> > "get()" the pointers and run their associated functions?
>
>Not easily.
>
>The Java 'interface' mechanism is designed to solve this type of problem.
>But it is applied at the class level, not at the individual method level.
>
> >>* Regarding variables ... within the bodies of functions/methods,
> >>variables should be declared before/as they are used, not at the
> >> beginning of the block.
>[snip]
> >> String simpleReplace(String str, String strFrom, String strTo) {
> >> int fromLength = strFrom.length();
> >> if (str == null || fromLength == 0)
> >> return str;
> >> int ipt;
> >> int ipt0;
> >> String sout = "";
> >> for (ipt0 = 0;
> >> ipt = str.indexOf(strFrom, ipt0);
> >> ipt0 = ipt + fromLength)
> >> sout += str.substring(ipt0, ipt) + strTo;
> >> sout += str.substring(ipt0, str.length());
> >> return sout;
> >> }
> >>
> >>
> >>
> > declaring them up front is a carryover for me from Visual Basic
> > EXPLICIT. But I can adjust.
>
>Yes. C programmers have the same issue.
>
>In C++ and Java you are encouraged to declare variables when you first
>assign them a value.
>
> > Still a bug there -- your int = definition
> > isn't boolean, I think.
>
>You are correct.
>
> > I like the while better, personally. I see I
> > forgot to test that, though. My bad.
>
>The reason that the 'for' is better is because it encapsulates and
>underscores the fact that you have an initial value that gets tested and
>updated each time through the loop.
>
>The while is more error-prone because the loop variable is separated from
>the update.
>
> > Is there any efficiency to be gained in .concat() relative to += ?
>
>No, they are exactly the same. The '+' and '+=' operations on strings are
>called 'syntactic sugar'.
>
> >>As a minor note, Java provides a StringBuffer data structure that may be
> >>more efficient when you are catting lots of things together.
> >>
> > so that's what that's for.
>
>Yep.
>
>In the early days of Java people used to say that StringBuffers were more
>efficient because they could be mutated.
>
>These days, the Java compiler optimizers are probably good enough that in
>many cases they can recognize when a String can be converted to a
>StringBuffer in a loop context.
>
> >>* getProperty should not take a 'returnType'
> >>
> >>
> >>
> >>
> > How does that work? Then it can take whatever type is being returned and
> > not turn that type into an Object? I'll look into that as well.
>
>I think that getProperty should always return an Object.
>
> > This is about all I can do this week on this. What are you working on?
>
>I am working on keeping up with you :-)
>
>
>Miguel
>
>
>
>-------------------------------------------------------
>This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
>for problems? Stop! Download the new AJAX search engine that makes
>searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
>http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
>_______________________________________________
>Jmol-developers mailing list
>[email protected]
>https://lists.sourceforge.net/lists/listinfo/jmol-developers
