How do I Create a Custom Property, part 666

[David Burgun]

>Hi David,
>
>>>...
>>>I'm afraid you are thinking far to complicated, especialy in this case....
>>No, I was thinging "simple", RR complicated IHMO, for instance, how is:
>>
>>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 :-)
>>>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,
>>>>that way you would never have to worry about the "empty" test.
>>>Are you sure? ;-)
>>Yes!
>
>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 if

In 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