Huh... >...after reading all those articles about parents, children, xtras, ancestors, inheritance...
I'd be afraid if you phrased it that way...unless I had some inheritance to worry about... lol:)))) Where is Irv's post in my Inbox anyway? Bloody Spam bolloxz...I've even managed to ban myself :)))) sorry dudes and dudesses(ziz the right way to spell it:) Irv!..are you around for a pint!? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Bochan Sent: 09 June 2004 19:06 To: [EMAIL PROTECTED] Subject: RE: <lingo-l> When and when Irv Kalb: > Congratualtions on your thesis! > > In just looking over the versions of > getPropertyDescriptionList from your post, both have errors. Sorry, I realized that only there after I hit "send". I wasd constantly thinking about not to forget to edit but I finally did. > GPDL #1 says that you are trying to build a list of members, > but what you are really displaying is a list of numbers. Jesus, how come wise people are aware of this but not me! > This is because you are just adding the value of the variable > "j" to the list. "j" is really just an integer. Oh, yes, that actually was the other point I was looking for: how to display the members' name instead of their consecutive numbers. To accomplish this I've made my own "wprkaround" (btw, the variable "theName" has been left in the message by mistake): repeat with j = 1 to nMembers if(member(j, "Assets").type = #bitmap) then theName = member(j).name picturesList.add(theName) else nothing end if end repeat but an approach offered by you was obviously more elegant and way more functional. > Further, while you are iterating over the number of members of castlib > "Assets", you are not checking the correct member in the if > statement. Finally, for speed, you should always use a local > variable when you have a repeat loop going up to some value > which is returned from a function. Got it, thanks! > In your case, 'the number of members of castlib "Assets"' will not > change during the > loop, so you should do the check once. Oh, why didn't I come to this conclusion by myself? > The code should look more like this (untested): > > property pVectorShape > > on getPropertyDescriptionList(me) > vectorShapesList = [] > nMembers = the number of members of castlib "Assets" -- > do this once here > repeat with j = 1 to the nMembers > if(member(j, "Assets").type = #vectorShape) then > vectorShapesList.add(member(j, "Assets")) > end if > end repeat > descriptionList = [:] > descriptionList.addProp(#pVectorShape, [#comment:"Which > one", #format:#member, #range:vectorShapesList, #default:1]) > return(descriptionList) > end Cool, now I'm the Lingo Pro! Only after you of course. > GPDL #2 has two errors. First, in your repeat loop you are > trying to access member(j, i), but "i" has no value. Then, > you are trying to add to the vectiorShapesList a variable > called "theName" but that is not defined either. > > > However, I believe that your general question is really about > when you should use a variable to store results of a > function. You should always use one if you are going to > re-use the value multiple times and the value doesn't change > (as in the description above). > However, the other case that you describe has to do with > using a local variable versus just using the results of a > function directly. > The answer is that it really is up to you. It really is a > matter of style. Here's an example: > > on someHandler > someVariable = function1(someParam) + > function2(someOtherParam) + someOtherVariable end > > versus: > > on someHandler > f1Result = function1(SomeParam) > f2Result = function2(SomeOtherParam) > someVariable = f1Result + f2Result + someOtherVariable end > > You will get the same answer whether you do, or do not use a > local variable. The main reasons to use local variable(s) > are for clarity and debugging. I personally like to use > local variables for intermediate results for debugging > purposes. If you store some intermediate result into a local > variable, you can set a breakpoint right after a call to a > function and ensure that the function is > returning the value you expected. It really helps track errors down > quickly. Further, by splitting things up into multiple lines > like this, I often find it easier to read. Oh, I see. But you know, the reason I'm actually afraid of using variables is that I'm not sure how much space in memory will they take. That is, after reading all those artciles about parents, children, xtras, ancestors, inheritance I hesitate much to use many variables because of cleanup. Maybe it's my skimming the documentation or some other issue but I'm definitely not going to give up. Never. > Others disagree with me and try to pack as much into a single > line as possible. > > Using local variables will be slightly more expensive > time-wise, but unless the function calls are made millions of > times, you will never notice a slowdown by using an > additional local variable. > > Irv Very many thanks to Multimedia Wrangler! Cheers --------- Peter Bochan Associate Assistant College of Foreign Languages Chernivtsi National University Ukraine [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!] [To remove yourself from this list, or to change to digest mode, go to http://www.penworks.com/lingo-l.cgi To post messages to the list, email [EMAIL PROTECTED] (Problems, email [EMAIL PROTECTED]). Lingo-L is for learning and helping with programming Lingo. Thanks!]
