How do I Create a Custom Property, part 666

[Klaus Major]

Hi David,

btw, you can call Klaus :-)

>> Hi David,
>>
>>>> ...
>>>> I'm afraid you are thinking far to complicated, especialy in this 
>>>> case....
>>> ...
> 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

Oh, sorry i meant this in respect to "mechanisms" like "lines" and 
"lists"...
I would rather say, it is more "verbose" ;-)

But OK, one "if...then..." handler is more complicated than none...

>> 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!

Then we all would have to "re-learn" very hard!!! ;-)

>>>> 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.

:-)

Sorry, not for me...

>>>> 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.

But it isn't this way...
So you better get used to it...

> 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!!!!!

No, no, this is semantically incorrect!
(Sorry for you, but semantics IS my hobby :-D

LINES are defined by the "linedelimiter" which is in fact the CR.

If we decide (like you suggested) to use the CR as an itemdelimiter, we 
would not be
able to differ "lines" anymore, because there is NO linedlimiter 
anymore to differ them...

So we would have to define another linedelimiter first :-)

And that would be the "END OF THE LINES" like we used to know, and 
therefore not acceptable :-)

> 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!

Oh, i never thought about this.
Maybe because this is the only "programming"-language i know... ;-)

But the way RR handles it, still sounds very logical to me...

And the end of one line is the beginning of the next one...
The old chicken and egg problem... (Attention: humor, joke!!!)

>>> 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,

That's for sure ;-)

> this is an effort to make sure we are both on the same page here:
> CR First Method..
> ..
> 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?

No :-D
But simply because it now simply is the way it was for the last 12 
years (in the life of the engine)
and i don't know otherwise...

And maybe because i know that it is idle to question things that won't 
change.
(...in the near and distance future... Just like the way the engine 
handles lines)

> All the Best
> Dave

Regards

Klaus Major
klaus at major-k.de
www.major-k.de


P.S.
We still don't know in what country you live in! ;-)