Skip to content

Request #48358 insertBeforeOffset() and insertAfterOffset() methods for ... #288

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 5 commits into from

Conversation

MarkBaker
Copy link
Contributor

...SplDoublyLinkedList

Adds new methods to insert a node in the middle of the dll object

Mark Baker added 3 commits February 22, 2013 14:11
…or SplDoublyLinkedList

Adds new methods to insert a node in the middle of the dll object
…plDoublyLinkedList

Modify code to use correct /* */ commenting and ensure that all indents are tabs rather than spaces
…plDoublyLinkedList

Additional tests for function argument validation
@colder
Copy link
Contributor

colder commented Mar 8, 2013

Previous discussion on this: https://bugs.php.net/bug.php?id=48358

I agree that doubly linked lists need this ability to add elements in their inner content. The implementation seems OK (+- whitespaces). I however have some concern that with that patch, they interface of DLL becomes (even more) odd:

To modify the content, you have: offsetSet, offsetUnset, and insertAfterOffset, insertBeforeOffset

@MarkBaker
Copy link
Contributor Author

What are you suggesting: that they should be offsetInsertBefore() and offsetInsertAfter()?

@MarkBaker MarkBaker closed this Mar 8, 2013
@MarkBaker MarkBaker reopened this Mar 8, 2013
@colder
Copy link
Contributor

colder commented Mar 8, 2013

Well, I'm not sure, since offset* comes from ArrayAccess.

But I would rather have some general-purpose discussion about interfaces of collections rather than adding one method at a time that we will not be able to rename in the future.

@dsp
Copy link
Member

dsp commented Mar 8, 2013

I honestly fear that we are not reaching a conclusion on how to name the interfaces (and particularly as we cannot rename existing methods). Nevertheless I do think a linkedlist must have these methods similar methods to add elements to after an arbitrary poisiton.

@dsp
Copy link
Member

dsp commented Mar 8, 2013

After an discussion with @colder, I think the best way to go is dropping insertAfter and adding a

add(int $index, mixed $newval)

similar to Javas API. It behaves like insertBefore. The insertAfter can be easily written as a userland function using the add method. This way we keep things simple and our interface is similar to the Java LinkedList and C# LinkedList

EDIT: NInja edit. Java add behaves like insertBefore not insertAfter..

@salathe
Copy link
Contributor

salathe commented Mar 8, 2013

I think the best way to go is dropping insertAfter and adding a

add(int $index, mixed $newval)

👍 since insertAfterOffset($offset, $newval) might as well be add($offset+1, $newval). I don't see a compelling reason to have this split over two methods.

@MarkBaker
Copy link
Contributor Author

The only argument I can think of for having both before and after versions is for after with an index of the last entry, effectively pushing a new value; but as push() is already available, this functionality is already available anyway.
With some minor mods, add($offset+1, $newval) can still do this when $offset is the last entry in the list; so I'll make those changes and rewrite the tests

…plDoublyLinkedList

Removed DLL insertAfterOffset() method; and renamed insertBeforeOffset() as add()
Modified add() to handle a push if specified index = count of elements already in the DLL, while still adding before the specified index otherwise
Adjusted tests accordingly to reflect the changes
@MarkBaker
Copy link
Contributor Author

Changes duly made as suggested to provide a single add() method

@salathe
Copy link
Contributor

salathe commented Mar 10, 2013

This suggestion might be a bit iffy, but I'd quite like a NULL offset to act the same as specifying count(…). It would be consistent with offsetSet() and would save having to call count()—though why you would use add() for this rather than offsetSet() or push(), I don't know. Just a thought.

@colder
Copy link
Contributor

colder commented Mar 11, 2013

I think if you want to push to the linked list, you would use push. It makes much more sense and is more readable than add(null, $value)

@dsp
Copy link
Member

dsp commented Mar 16, 2013

I dont think we should handle NULL special. Anyway the patch looks good to me and if there are no objections I will merge it before beta1.

@salathe
Copy link
Contributor

salathe commented Mar 16, 2013

Sounds good to me. 🐹

SEPARATE_ARG_IF_REF(value);

intern = (spl_dllist_object*)zend_object_store_get_object(getThis() TSRMLS_CC);
index = (int)spl_offset_convert_to_long(zindex TSRMLS_CC);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does this have an (int) cast? index is declared as long, so the types should match.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mainly for the same reason that I wasn't certain why offsetUnset() also casts to int, while other methods like offsetExists() and offsetGet() don't: I wasn't sure if I was missing something elsewhere in the code, and preferred to err on the side of caution.... or is offsetUnset() also wrong in this cast?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems wrong to me, I will fix offsetunset.

EDIT: Done

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In that case, I'll happily change add() and push again

Don't cast index to an int, leave it as a long
@dsp
Copy link
Member

dsp commented Mar 19, 2013

I squashed the branch to one commit and removed the newline changes and pushed it as 4257469. Thanks for the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants