Whether it makes sense or not depends on what you're trying to
accomplish. You could just be taking the items in order. Granted, the
example may have been lame, but the point was that working backward from
value was no guarantee that you got the matching property.
That said, I think if Kerry's list was structured a little differently to
begin with, the whole thing might be easier. Maybe #words is a property
that matches up with a linear list of words, so you just extract the
wordlist and then you have your list of words.
However, I don't know all the requirements of what she's doing, so I won't
try to second-guess the design.
- Tab
At 04:26 PM 3/28/01 +0100, Karina Steffens wrote:
>Hi Tab,
>
> > a prop for a given value, which besides being slow(er), will
> > fail if you
> > have the same value under two different props. Consider:
> >
> > m=[#Name:"Joe", #Password:"Joe", #Name:"Bill", #Password:"Bill"]
> >
> > Under your approach, if you do a getOne(m, "Joe"), you'll
> > always get #Name,
> > which is the first property that has a value that matches.
>
>True, but Kerry's list is very different (and weird) - each property has a
>list all of it's own, so there's no chance of conflict.
>
>Also, I'd never use a list like in your example. "I'm only an egg", but I'm
>strongly convinced that it's using the wrong syntax.
>It should really be:
>
>m=[[#Name:"Joe", #Password:"Joe"], [#Name:"Bill", #Password:"Bill"]]
>
>Otherwise, there's nothing connecting the password to the name. "Bill" is
>just as likely to be the password for "Joe" as it is for "Bill"...
>If nothing else, how would you use the syntax list[#name]? Would it be "Joe"
>or "Bill"?
>
>If you consider property lists, each list is an object. To prove my point,
>I'll convert both lists into parent scripts:
>
>First list structure:
>
>property name
>property password
>property name
>property password
>
>on new me
> name = "Joe"
> password = "Joe"
> name = "Bill"
> password = "Bill"
> return me
>end
>
>You can see right away that it makes no sense...
>For one thing, "Bill" will always overwrite "Joe". Also, I doubt if you'd
>even be able to compile it.
>
>Second list structure:
>
>Parent script1:
>
>property name
>property password
>
>on new me
> name = "Joe"
> password = "Joe"
> return me
>end
>
>Parent script2:
>
>property name
>property password
>
>on new me
> name = "Bill"
> password = "Bill"
> return me
>end
>
>(This is a simplified illustration. In reality you wouldn't write it out as
>two seperate parent scripts...)
>
>It's the same with property lists. Director might compile it ok, but even if
>you'd manage to make it work by enumeration, you might as well make it
>linear (aside from the bit where there's nothing connecting the #password to
>the #name)
>
>
>I hope all that ranting made some kind of sense :)
>
>Karina
>
>
>
>
>[To remove yourself from this list, or to change to digest mode, go to
>http://www.penworks.com/LUJ/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/LUJ/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!]
