Hi David,
No, I was thinging "simple", RR complicated IHMO, for instance, how is:... I'm afraid you are thinking far to complicated, especialy in this case....
if myNewCustomProp is empty then put return & "myNewCustomProp" after myCustomKeys
simpler than:
put "myNewCustomProp" after myCustomKeys
I don't hink that the terms "simple" or "difficult" apply here...
I was refering you your remark above "you are thinking far to complicated" that's where is the simple/difficult terms came into it. So, it should read:
if myCustomKeys is empty then put "myNewCustomProp" into myCustomKeys else put return & "myNewCustomProp" after myCustomKeys end if
is more *complicated* than:
put "myNewCustomProp" & return after myCustomKeys
The programmer/scripter is responsible for supplying data to the engine in a format
that the engine can handle...
The engien gives a damn about empty lines, but YOUR scripts may cause trouble in that case...
What I mean is that surely it would be better for the "engine" to expect lines to be *terminated* by a CR *always*. Then it wouldn't have to worry about the case where there is only one line in the container and nor would the script!
Most things in RR are "natural", i mean they are just like they are, no misteries :-)Yes!
Therefore i suggested to think of a list as a field (maybe with "listbehaviour" set to true)...But anyway, surely it would be MUCH better to have each item finish with a return,Are you sure? ;-)
that way you would never have to worry about the "empty" test.
Quod erat demonstrandum! ;-)
See above example.
Even in that case you could end up with an empty item, if you don't check for "emptyness"!!!How so? If you always did:
put "myNewCustomProp" & return after myCustomKeys
this would work regardless of the current contents of myCustomKeys!
Of course you'd get an empty line if you just did:
put return after myCustomKeys
but in that case you'd be explicity asking for an empty line and the same would be true of appending the return to the start of the new property anyway!
You are exspecting a "thinking" engine?
There is no need for "thinking" or at least anymore "thinking" than is being done at present and probably less "thinking" would be necessary.
"Hmmm, put "myNewCustomProp" & return after myCustomKeys? That will procude an empty line!
I am sure the user does not want this, so i simply delete the trailing CR when nobody is looking..." :-D
Well, if you (or the engine or whatever) handles it that way, sure, BUT I am saying that if the rule was that each "line" was *always* terminated by a return, then you wouldn't need to do anything special and there would never be a case where the script code would have to be complicated (see above) to append a line.
There are two cases here, one of the container of the lines being empty (e.g. containing no lines), which you have to test for each time you append using the "CR first" approach. The second is an Empty line within the container and that is the same in both cases, except that using the "return first" method means that you have 4 extra lines of code everytime you want to append a line to that container.
I just tried this
See below...
And how could you differ LINES in that case? Sorry, but that would not work.
Don't understand what you mean "differ LINES".
You suggested to separate "items" by CR, and that way, we could not differ "lines", because then
CR would not separate "lines" anymore! ;-)
Yes, they would!!!!! For instance the lines in a text file l are seperate lines and guess what? In 99.99999999% of cases the seperation character is at the END of a line, not at the start of the next one!
Why wouldn't the above work? Seems to me like it would work better than what is there already.
Sure, with a "thinking" engine, that takes care of empty lines...
Not necessary, blank lines can be added in both cases and the code in the "engine" would be the same in both cases.
Surely it is better to handle as much as possible in the "engine" *once*, rather than have to have 4 extra lines of Script code which must be typed by everyone using the "engine" multiple times!
From re-reading, I think we are talking at cross purposes, this is an effort to make sure we are both on the same page here:
CR First Method.
To avoid appending an empty line to a "Lines contaner" (called myLineList from now on), each time a line is appended to the container, the following must be performed:
--
-- myNewLine contains the line to be appended
--
if myNewLine is not empty then
if myLineList is empty then
put myNewLine into myLineList
else
put return & myNewLine after myLineList
end if
end ifIn this case you have to test that the CONTAINER is not empty, since if it is you will add a spurious empty line to the list. This is implicitly taken care of if you always use the CR last method which makes everyones life easier!
CR Last Method.
-- -- myNewLine contains the line to be appended -- if myNewLine is not empty then put return & myNewLine after myLineList end if
This is always assuming that it is illegal to have an empty line in the list, if it's not, then you just remove:
if myNewLine is not empty end if
However, I was talking about an empty list CONTAINER not the item that was being appended, which is where I think the confusion has crept in. In the case which I first posted, it was impossible for a empty line to be appended since I was actually setting the value explicitly in the script.
Hope this clears up the misunderstanding.
Wouldn't you agree that the CR Last Method is simpler/easier/better?
All the Best Dave
All the Best Dave _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
