Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 24 Aug 2016, at 10:39 PM, Kay C Lan  wrote:
> 
> As does this situation where combine/split doesn't round-trip

That’s a good one!

http://quality.livecode.com/show_bug.cgi?id=18259 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Kay C Lan]

On Sun, Aug 21, 2016 at 7:52 AM, Monte Goulding  wrote:
>
>> On 21 Aug 2016, at 9:38 AM, Randy Hengst  wrote:
>>
>> This doesn’t totally fit with the conversation, and I assume the Team knows 
>> this but… SORT assumes that a trailing comma indicates an empty item
>
> Oh yay…. this behavior persists in LiveCode 8.

As does this situation where combine/split doesn't round-trip, in the msg box:

put 9 into Array[1]
put empty into Array[2]
put 7 into Array[3]
put empty into Array[4]
combine Array using comma
put Array & cr into msg
split Array using comma
put the keys of Array after msg

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Ben Rubinstein]

On 21/08/2016 00:22, Monte Goulding wrote:

On 21 Aug 2016, at 8:57 AM, Richard Gaskin  wrote:
>
> It would appear that the current behavior in v8 is a fix that addresses a previously 
anomalous handling of delimiters in the case of "is among".

That’s my feeling also. We know it impacts a popular library (Animation 
Engine), however, seeing as any code base that needs to be robust on all 
versions of LiveCode will need to ensure it doesn’t rely on empty trailing 
items with no delimiter after them I assume that will be need to be resolved 
regardless because all the 8.0.x series are impacted and a number of 7.x (we 
need to determine which ones).


FWIW - that's my feeling too. There's no completely pain-free option here: 
better to take the path of increased consistency with a simple model.


Ben

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[hh]

Thank you all very much for the detailed and patient information.

Yes, there was a big misunderstanding about RTL/LTR by me, because
language-script directions can be deliberately mixed ('bidirectional',
as I read in an LC 7 introductory blog).
>From that I concluded erroneously a wrong in-memory storage order.

Also languages that can be written 'bidirectional', in not only one
script, or (quoted) passages in a language script opposite to the
current direction can make the string in question deliberately
complicated (at least for me).

I think that I understand your explanations (hope so..).
--> Except the case of a trailing item delimiter, Monte's original
--> thread-question.

If a string has the in-memory storage order of "ENO,OWT,".
Is empty among its items? What is its display?

===
> Mark W. wrote:
> Perhaps there's a misunderstanding here...
> 
> If when you refer to rtl to mean rtl languages (such as Arabic) then there
> is nothing to do - rtl languages are stored in memory in logical order - ie 
> the
> same way round as ltr languages. It is just the display which is changed.
> 
> If you mean doing chunk searching from high indicies to low then that would 
> just
> be equivalent to reversing the order of the chars in the target string and 
> then
> using the current operations on it (from what you've said about the suggested
> semantics).
===
> Fraser G. wrote:
> I think there's a bit of a misunderstanding here about how LiveCode
> handles LTR and RTL: the two are only different when being displayed in
> a field. At all other times, they are exactly the same. LiveCode always
> stores text in reading order (that is, the order that the person
> familiar with the LTR/RTL language in question would read the words) not
> the order that the words would be displayed on screen. Using the
> convention in Unicode where LTR text is in lowercase and RTL is in
> uppercase, the string displayed as
> 
> three,TWO,ONE
> 
> would have in-memory storage order of
> 
> ENO,OWT,three
> 
> and, therefore, the items of the string would be "ONE", "TWO" and
> "three" (in that order). If done otherwise, inserting a small piece of
> RTL text into a larger LTR list would completely break processing!
> Whereas, this way, "first" is a completely language-neutral concept. The
> fact that the first item appears on the left-hand side is simply because
> we're using an LTR language, not because LiveCode counts from the left.
> 
> The reason "three,TWO,ONE" has the first item displayed on the right is
> because, in the absence of other information, the first LTR/RTL
> character in the string determines the primary display order. If the
> string had another item "zero" inserted before the first item, the
> display order would change to
> 
> zero,ONE,TWO,three
> 
> with a storage order of
> 
> zero,ENO,OWT,three
> 
> Again, only display cares about LTR/RTL. For every other purpose,
> strings are sequences of characters with no inherent direction.
> 
> If you're feeling confused about LTR/RTL, remember this: don't do
> anything differently. Pretend it doesn't exist and LiveCode will do all
> the hard work for you. There is nothing special about it except that
> characters are displayed in a different order.
===
> Hermann H. wrote:
>> Ali,
>> probably it's about time that you give at RTL-lesson/blog/tutorial?
>> Would be very appreciated.
>> 
>>> Ali wrote:
>>> the number of items in 'ab' is not an invariant of its read order,
>>> unless you reverse the characters in the delimiter too.
>>> When the item delimiter is 'aa', the items of 'baaa' are completely
>>> different. What happens when the item delimiter has combining
>>> characters and we're matching the precombined version?
>> 
>> Not reversing the LTR-delimiter to a RTL-delimiter changes the delimiter:
>> Isn't it planned to introduce RTL-multichar-delimiters to solve this?
>> 
>>> For a more simple example of the issues here, what are the backward
>>> and forward words of
>>> "String without closing quote
>> 
>> RTL and LTR (should) have exactly the same words/truewords (seen as a counted
>> set) and the same number of words/truewords. Right?
>> 
>> Anyway, this is not my point, because words/truewords cannot be empty
>> (except as the non-existent ones 'out-of-bounds') contrary to items or lines.
>> 
>> My point is, that a _trailing_ LTR delimiter 'item' or 'line' that is ignored
>> becomes a _leading_ RTL delimiter (delimiter also RTL), for the same string.
>> 
>> Thus the number of items or lines increases by one, because the LTR ignored 
>> empty
>> 'item' or 'line' becomes a RTL not-ignored empty 'item' or 'line' 
>> respectively.
>> And the result of "empty is among the items of" (should be an 
>> order-independent
>> "element-of-check") may switch from LTR-false to RTL-true, for the same 
>> string,
>> and for the same one-char-delimiter (or also reversed multichar-delimiter).
> 


___
use-livecode mailing list

Re: Backwards compatibility or sanity? help

[Fraser Gordon]

On 21/08/2016 15:26, hh wrote:
> Ali,
> probably it's about time that you give at RTL-lesson/blog/tutorial?
> Would be very appreciated.
>
>> Ali wrote:
>> the number of items in 'ab' is not an invariant of its read order,
>> unless you reverse the characters in the delimiter too.
>> When the item delimiter is 'aa', the items of 'baaa' are completely
>> different. What happens when the item delimiter has combining
>> characters and we're matching the precombined version?
> Not reversing the LTR-delimiter to a RTL-delimiter changes the delimiter:
> Isn't it planned to introduce RTL-multichar-delimiters to solve this?
>
>> For a more simple example of the issues here, what are the backward
>> and forward words of
>> "String without closing quote
> RTL and LTR (should) have exactly the same words/truewords (seen as a counted
> set) and the same number of words/truewords. Right?
>
> Anyway, this is not my point, because words/truewords cannot be empty
> (except as the non-existent ones 'out-of-bounds') contrary to items or lines.
>
> My point is, that a _trailing_ LTR delimiter 'item' or 'line' that is ignored
> becomes a _leading_ RTL delimiter (delimiter also RTL), for the same string.
>
> Thus the number of items or lines increases by one, because the LTR ignored 
> empty
> 'item' or 'line' becomes a RTL not-ignored empty 'item' or 'line' 
> respectively.
> And the result of "empty is among the items of" (should be an 
> order-independent
> "element-of-check") may switch from LTR-false to RTL-true, for the same 
> string,
> and for the same one-char-delimiter (or also reversed multichar-delimiter).
>
> Salut, Hermann

I think there's a bit of a misunderstanding here about how LiveCode
handles LTR and RTL: the two are only different when being displayed in
a field. At all other times, they are exactly the same. LiveCode always
stores text in reading order (that is, the order that the person
familiar with the LTR/RTL language in question would read the words) not
the order that the words would be displayed on screen. Using the
convention in Unicode where LTR text is in lowercase and RTL is in
uppercase, the string displayed as

three,TWO,ONE

would have in-memory storage order of

ENO,OWT,three

and, therefore, the items of the string would be "ONE", "TWO" and
"three" (in that order). If done otherwise, inserting a small piece of
RTL text into a larger LTR list would completely break processing!
Whereas, this way, "first" is a completely language-neutral concept. The
fact that the first item appears on the left-hand side is simply because
we're using an LTR language, not because LiveCode counts from the left.

The reason "three,TWO,ONE" has the first item displayed on the right is
because, in the absence of other information, the first LTR/RTL
character in the string determines the primary display order. If the
string had another item "zero" inserted before the first item, the
display order would change to

zero,ONE,TWO,three

with a storage order of

zero,ENO,OWT,three

Again, only display cares about LTR/RTL. For every other purpose,
strings are sequences of characters with no inherent direction.

If you're feeling confused about LTR/RTL, remember this: don't do
anything differently. Pretend it doesn't exist and LiveCode will do all
the hard work for you. There is nothing special about it except that
characters are displayed in a different order.

Fraser

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Mark Waddingham]

Perhaps there's a misunderstanding here...

If when you refer to rtl to mean rtl languages (such as Arabic) then there is 
nothing to do - rtl languages are stored in memory in logical order - ie the 
same way round as ltr languages. It is just the display which is changed.

If you mean doing chunk searching from high indicies to low then that would 
just be equivalent to reversing the order of the chars in the target string and 
then using the current operations on it (from what you've said about the 
suggested semantics).

Can you clarify your use-case?

Warmest Regards,

Mark.

Sent from my iPhone

> On 21 Aug 2016, at 15:26, hh  wrote:
> 
> Ali,
> probably it's about time that you give at RTL-lesson/blog/tutorial?
> Would be very appreciated.
> 
>> Ali wrote:
>> the number of items in 'ab' is not an invariant of its read order,
>> unless you reverse the characters in the delimiter too.
>> When the item delimiter is 'aa', the items of 'baaa' are completely
>> different. What happens when the item delimiter has combining
>> characters and we're matching the precombined version?
> 
> Not reversing the LTR-delimiter to a RTL-delimiter changes the delimiter:
> Isn't it planned to introduce RTL-multichar-delimiters to solve this?
> 
>> For a more simple example of the issues here, what are the backward
>> and forward words of
>> "String without closing quote
> 
> RTL and LTR (should) have exactly the same words/truewords (seen as a counted
> set) and the same number of words/truewords. Right?
> 
> Anyway, this is not my point, because words/truewords cannot be empty
> (except as the non-existent ones 'out-of-bounds') contrary to items or lines.
> 
> My point is, that a _trailing_ LTR delimiter 'item' or 'line' that is ignored
> becomes a _leading_ RTL delimiter (delimiter also RTL), for the same string.
> 
> Thus the number of items or lines increases by one, because the LTR ignored 
> empty
> 'item' or 'line' becomes a RTL not-ignored empty 'item' or 'line' 
> respectively.
> And the result of "empty is among the items of" (should be an 
> order-independent
> "element-of-check") may switch from LTR-false to RTL-true, for the same 
> string,
> and for the same one-char-delimiter (or also reversed multichar-delimiter).
> 
> Salut, Hermann
> 
> 
> 
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[hh]

Ali,
probably it's about time that you give at RTL-lesson/blog/tutorial?
Would be very appreciated.

> Ali wrote:
> the number of items in 'ab' is not an invariant of its read order,
> unless you reverse the characters in the delimiter too.
> When the item delimiter is 'aa', the items of 'baaa' are completely
> different. What happens when the item delimiter has combining
> characters and we're matching the precombined version?

Not reversing the LTR-delimiter to a RTL-delimiter changes the delimiter:
Isn't it planned to introduce RTL-multichar-delimiters to solve this?

> For a more simple example of the issues here, what are the backward
> and forward words of
> "String without closing quote

RTL and LTR (should) have exactly the same words/truewords (seen as a counted
set) and the same number of words/truewords. Right?

Anyway, this is not my point, because words/truewords cannot be empty
(except as the non-existent ones 'out-of-bounds') contrary to items or lines.

My point is, that a _trailing_ LTR delimiter 'item' or 'line' that is ignored
becomes a _leading_ RTL delimiter (delimiter also RTL), for the same string.

Thus the number of items or lines increases by one, because the LTR ignored 
empty
'item' or 'line' becomes a RTL not-ignored empty 'item' or 'line' respectively.
And the result of "empty is among the items of" (should be an order-independent
"element-of-check") may switch from LTR-false to RTL-true, for the same string,
and for the same one-char-delimiter (or also reversed multichar-delimiter).

Salut, Hermann



___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Ali Lloyd]

Hermann,
Symmetric chunks of the type you describe have issues when the delimiting
rules are more complex - for example when the item delimiter is 'ab', the
number of items in 'ab' is not an invariant of its read order, unless you
reverse the characters in the delimiter too. When the item delimiter is
'aa', the items of 'baaa' are completely different. What happens when the
item delimiter has combining characters and we're matching the precombined
version?

For a more simple example of the issues here, what are the backward and
forward words of

"String without closing quote

?

On Sun, 21 Aug 2016 at 10:39, hh  wrote:

> > Monte wrote:
> > Hmm... I've got to say I'm a little on the ignorant
> > side of things with regard to RTL text in LiveCode but
> > my understanding is it's only a field thing and any
> > chunk references are always LTR. Happy to be educated
> > though!
>
> Sorry Monte,
> I thought (erroneously?) that right-to-left chunk references
> are in the to-do-but-not-yet-implemented-chest of LC 8.
>
> Anyway, the following example
>
> empty is among the items of empty --> returns false
> item 1 of empty is empty --> returns true
>
> shows, that one could think about
> == adding a new "correct/consistent" definition of item, e.g.
>"trueItem", that is free of all these contradictions
>generating trailing delimiter and 'index is out of bounds'
>things,
> == and about making the (sometimes) "wrong/inconsistent"
>item-behaviour always downward compatible.
>
> Ciao, Hermann
>
>
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[hh]

> Monte wrote:
> Hmm... I've got to say I'm a little on the ignorant
> side of things with regard to RTL text in LiveCode but
> my understanding is it's only a field thing and any
> chunk references are always LTR. Happy to be educated
> though!

Sorry Monte,
I thought (erroneously?) that right-to-left chunk references
are in the to-do-but-not-yet-implemented-chest of LC 8.

Anyway, the following example

empty is among the items of empty --> returns false
item 1 of empty is empty --> returns true

shows, that one could think about
== adding a new "correct/consistent" definition of item, e.g.
   "trueItem", that is free of all these contradictions
   generating trailing delimiter and 'index is out of bounds'
   things,
== and about making the (sometimes) "wrong/inconsistent" 
   item-behaviour always downward compatible.

Ciao, Hermann


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

Hmm... I've got to say I'm a little on the ignorant side of things with regard 
to RTL text in LiveCode but my understanding is it's only a field thing and any 
chunk references are always LTR. Happy to be educated though!

Cheers

Monte

Sent from my iPhone

> On 21 Aug 2016, at 6:06 PM, hh  wrote:
> 
> RTL


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[hh]

> > Hermann wrote: 
> > Why is the number of items or having the property "item" 
> > of a string dependent on the writing/reading direction 
> > of the string?

> Monte wrote:
> Hmm… I’ll answer your question with a question: Which item is item 1?

The string "a," has currently ..
[RTL] .. reading (or embedding) the string right-to-left:
  two items and empty is among its items.
  RTL-item 1 is empty, RTL-item 2 is "a".
[LTR] .. reading (or embedding) the string left-to-right:
  one item and empty is not among its items.
  LTR-item 1 is "a". And LTR-item 2 is empty
  (item 2 of "a," is empty --> returns true).

Moreover, similar:
empty is among the items of empty --> returns false
item 1 of empty is empty --> returns true


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 21 Aug 2016, at 9:52 AM, Monte Goulding  wrote:
> 
> Oh yay…. this behavior persists in LiveCode 8.


There is an ANOMALY report on this:

http://quality.livecode.com/show_bug.cgi?id=16588 

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 21 Aug 2016, at 9:46 AM, hh  wrote:
> 
> Why is the number of items or having the property "item"
> of a string dependent of the writing/reading direction
> of the string?

Hmm… I’ll answer your question with a question:

Which item is item 1?

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 21 Aug 2016, at 9:38 AM, Randy Hengst  wrote:
> 
> This doesn’t totally fit with the conversation, and I assume the Team knows 
> this but… SORT assumes that a trailing comma indicates an empty item

Oh yay…. this behavior persists in LiveCode 8.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[hh]

Why is the number of items or having the property "item"
of a string dependent of the writing/reading direction
of the string?


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Randy Hengst]

This doesn’t totally fit with the conversation, and I assume the Team knows 
this but… SORT assumes that a trailing comma indicates an empty item… for 
example:

on mouseUp
   local tTestITEMS
   
   put "1,2,3,4,5," into tTestITEMS
   answer the number of items in tTestITEMS && "ITEMS" && "tTestITEMS" && 
tTestITEMS
   -- will give FIVE items

   
   sort items of tTestITEMS by random(1)
   answer the number of items in tTestITEMS && "ITEMS" && "tTestITEMS" && 
tTestITEMS
   -- will give SIX items

end mouseUp

be well
randy hengst
www.classroomFocusedSoftware.com



> On Aug 20, 2016, at 6:22 PM, Monte Goulding  wrote:
> 
> 
>> On 21 Aug 2016, at 8:57 AM, Richard Gaskin  
>> wrote:
>> 
>> It would appear that the current behavior in v8 is a fix that addresses a 
>> previously anomalous handling of delimiters in the case of "is among".
> 
> That’s my feeling also. We know it impacts a popular library (Animation 
> Engine), however, seeing as any code base that needs to be robust on all 
> versions of LiveCode will need to ensure it doesn’t rely on empty trailing 
> items with no delimiter after them I assume that will be need to be resolved 
> regardless because all the 8.0.x series are impacted and a number of 7.x (we 
> need to determine which ones).
> 
> Cheers
> 
> Monte
> ___
> use-livecode mailing list
> use-livecode@lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription 
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 21 Aug 2016, at 8:57 AM, Richard Gaskin  wrote:
> 
> It would appear that the current behavior in v8 is a fix that addresses a 
> previously anomalous handling of delimiters in the case of "is among".

That’s my feeling also. We know it impacts a popular library (Animation 
Engine), however, seeing as any code base that needs to be robust on all 
versions of LiveCode will need to ensure it doesn’t rely on empty trailing 
items with no delimiter after them I assume that will be need to be resolved 
regardless because all the 8.0.x series are impacted and a number of 7.x (we 
need to determine which ones).

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Richard Gaskin]

Monte Goulding wrote:

>> On 21 Aug 2016, at 8:47 AM, Richard Gaskin wrote:
>>
>> The current behavior for Trevor's test is consistent with item
>> counts. If we change it we open up that can of worms about
>> delimiters all over again, and undo Mark's thinking on this.
>
> Yes the point is there’s a legacy of `is among` behaving differently
> than other delimiter iterators. So I guess we need to determine if we
> consider the change in behavior in LiveCode 8 a fix to a bug or a
> regression to a behavior.

It would appear that the current behavior in v8 is a fix that addresses 
a previously anomalous handling of delimiters in the case of "is among".


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Monte Goulding]

> On 21 Aug 2016, at 8:47 AM, Richard Gaskin  wrote:
> 
> The current behavior for Trevor's test is consistent with item counts. If we 
> change it we open up that can of worms about delimiters all over again, and 
> undo Mark's thinking on this.

Yes the point is there’s a legacy of `is among` behaving differently than other 
delimiter iterators. So I guess we need to determine if we consider the change 
in behavior in LiveCode 8 a fix to a bug or a regression to a behavior.

Cheers

Monte
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Backwards compatibility or sanity? help

[Richard Gaskin]

Monte Goulding wrote:

> The team is in a quandary about the following bug:
>
> http://quality.livecode.com/show_bug.cgi?id=18145
>
> The issue is in LiveCode 6.7 and below `is among` was essentially
> implemented incorrectly meaning that you could get results like this:
>
> put the number of items in "test,this," & comma & \
>  (empty is among the items of "test,this,")
> —> 2,true
>
> In LiveCode 7 this (fairly odd) behavior was broken and fixed in the
> early dp releases then broken again when another fix was made. The
> difficulty is trailing delimiters are ignored by all the other things
> like repeat etc.
>
> So the situation at the moment in LiveCode 8 is:
>
> put the number of items in "test,this," & comma & \
>  (empty is among the items of "test,this,")
> —> 2,false
>
> Note that in all versions:
>
> repeat for each item tItem in "test,this,”
>— iterates twice with “test” then “this"
> end repeat
> — here tItem is “this"
>
> It’s important to note that this is only an issue if the last item is
> empty and meant to be an empty item.
>
> I personally would rather not revert to the anomalous behavior of `is
> among` as I think it is doing the platform and users a disservice to
> persist in maintaining it.
>
> I’m interested in your thoughts!

We've had numerous lengthy (and sometimes heated) discussions about 
whether a string ending in a delimiter is considered have a thing after 
that delimiter.


Most often this comes up with item/line counting, e.g.:

  the number of items of "test,this,"

Current that returns 2.

I believe the last time this was discussed Mark had explained why a 
string ending with a delimiter means there is no item beyond that 
delimiter.  IIRC it boils down to the delimiter being the end of a 
thing, but not a separator between things.


Given that, we would expect this:

 (empty is among the items of "test,this,")

...to be false, while this:

 (empty is among the items of "test,,this")

...would return true.

The current behavior for Trevor's test is consistent with item counts. 
If we change it we open up that can of worms about delimiters all over 
again, and undo Mark's thinking on this.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode