I would lean towards making it become null, because I like to have
"less magic" when possible.
But I don't feel too strongly about it in this case. David Temkin
tended to like to have a little more "magic" in the language, to make
it easier for people to put apps together faster with
less code, but I find it easier when learning an API if the methods
have simpler behaviors with less special cases, which are are easy to
remember and describe.
Keeping the old
behavior would also be one less thing to worry about to make life
easier for people porting their existing apps to 4.2.
On Tue, Dec 2, 2008 at 11:26 AM, André Bargull <[EMAIL PROTECTED]> wrote:
> If you delete a node (call it "A") through "LzDatapointer#deleteNode()" and
> if this node has got a next sibling (call it "B"), the datapointer will
> delete "A" and then select "B".
> But if "A" has no next sibling, but a previous sibling (call it "C"), the
> changed method will select "C" instead, but before the pointer was set to
> `null`.
> I said it is more reasonable to select any possible sibling (next _and_
> previous), but the testcases seem to require that _no_ previous sibling is
> selected. Changing the testcases to match the new semantics is surely
> possible, but maybe there is some reason not to select the previous sibling.
> Any ideas?
>
>
> Ok, here's a simple example which will work in trunk-nightly.
>>
>> <canvas debug="true" >
>> <dataset name="ds" >
>> <items>
>> <item id="a" />
>> <item id="b" />
>> </items>
>> <items>
>> <item id="c" />
>> <item id="d" />
>> </items>
>> </dataset>
>>
>> <handler name="oninit" >
>> var dp1 = ds.getPointer();
>> dp1.setXPath("/items[1]/item[1]");
>> Debug.write("valid = %w", dp1.isValid());
>> dp1.deleteNode();
>> Debug.write("valid = %w, id='%s' (expect '%s')", dp1.isValid(),
>> dp1.getNodeAttribute("id"), "b");
>>
>> var dp2 = ds.getPointer();
>> dp2.setXPath("/items[2]/item[2]");
>> Debug.write("valid = %w", dp2.isValid());
>> dp2.deleteNode();
>
>> // this will work in trunk-nightly, but not in earlier versions
>>
>> Debug.write("valid = %w, id='%s' (expect '%s')", dp2.isValid(),
>> dp2.getNodeAttribute("id"), "c");
>> </handler>
>> </canvas>
>
>
>
>
> On 12/2/2008 5:10 PM, Henry Minsky wrote:
>>
>> Oh sorry, I should have sent this to laszlo-dev....
>>
>>
>> On Tue, Dec 2, 2008 at 11:07 AM, André Bargull <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> [I've removed the cc for "Platform Team
>>> <[EMAIL PROTECTED]>"
>>> because I haven't got access to that mailing-list]
>>>
>>> I'll track it down and check the assertions in the test..
>>>
>>>
>>> On 12/2/2008 5:02 PM, André Bargull wrote:
>>>>
>>>> Ah, ok. The last change from Josh to "LzDatapointer#deleteNode()" is the
>>>> culprit. So actually my fault, since I've proposed that change and
>>>> approved
>>>> the change, too...
>>>>
>>>>
>>>> On 12/2/2008 4:41 PM, Henry Minsky wrote:
>>>>>
>>>>> No, actually I did a clean build in a clean top-of-tree trunk and I
>>>>> still get those errors. Looks like a real regression
>>>>> from something. I think I will try max's binary search tool to find
>>>>> which revision this happened in.
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Dec 2, 2008 at 10:35 AM, Henry Minsky
>>>>> <[EMAIL PROTECTED]>
>>>>> wrote:
>>>>>>
>>>>>> Actually, it looks like it's that changeset I just sent out for the
>>>>>> datapath sortorder is causing a failure, it seems like it's only
>>>>>> happening in my workspace that has that modification.
>>>>>>
>>>>>>
>>>>>> On Tue, Dec 2, 2008 at 10:23 AM, André Bargull <[EMAIL PROTECTED]>
>>>>>> wrote:
>>>>>>>
>>>>>>> That's the cachebreak-test, you need to run alldata another time,
>>>>>>> then
>>>>>>> it
>>>>>>> should work.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 12/2/2008 4:12 PM, Henry Minsky wrote:
>>>>>>>>
>>>>>>>> speaking of which , I am seeing these errors in alldata.lzx
>>>>>>>>
>>>>>>>> Tests: 325 Failures: 3 Errors: 0
>>>>>>>> TestFailure: test2 failed: False: expected false got true
>>>>>>>> TestFailure: test2 failed: False: expected false got true
>>>>>>>> TestFailure: test failed: False: expected false got true
>>>>>>>>
>>>>>>>> I'm tracking down which test it is now. I guess we ought to be
>>>>>>>> printing out the name of
>>>>>>>> the test suite class that is running to make clear which test suite
>>>>>>>> is
>>>>>>>> failing.
>>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Henry Minsky
>>>>>> Software Architect
>>>>>> [EMAIL PROTECTED]
>>>>>>
>>>>>
>>>>>
>>>>
>>
>>
>>
>
>
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
