#11128 closed feature (plugin)
Stack operations for the jQuery chain
Reported by: | gibson042 | Owned by: | gibson042 |
---|---|---|---|
Priority: | low | Milestone: | None |
Component: | unfiled | Version: | 1.7.1 |
Keywords: | Cc: | ||
Blocked by: | Blocking: |
Description
Since the jQuery chain is functionally a stack, it might be useful (for both documentation and development) to explicitly recognize it as such and expose stack operations upon it. To that purpose, I propose standardizing peek/pop nomenclature as "back" instead of "end", with the following implications:
stack | jQuery | implementation | notes |
---|---|---|---|
stack.push | .pushStack( elements [, name, selector] ) | already present and used by filters/traversing/etc. | |
stack.peek stack.pop | .back( [depth] ) | var ret = this; do { ret = ret.prevObject; } while ( ret && --depth >= 0 ); return ret || this.constructor(); | new method: .end should alias to this |
stack.push( stack.peek() + stack.peek(1) ) | .addBack( [depth] [, filter] ) | if ( typeof depth !== "number" ) { filter = depth; depth = 0; } var back = this.back( depth ); return this.add( filter == null ? back : back.filter( filter ) ); | new method: .andSelf should alias to this |
stack.length | depth | not implemented unless we replace .prevObject with an array |
Change History (6)
comment:1 Changed 11 years ago by
comment:2 Changed 11 years ago by
It is a linear collection restricting addition and removal to the same end. The linked list implementation is not relevant to the stack interface, which is the subject of this ticket.
comment:3 Changed 11 years ago by
Owner: | set to gibson042 |
---|---|
Priority: | undecided → low |
Status: | new → pending |
@gibson042: even if it's a collection that restricts addition and removal to the same end, could you justify why this set of changes would be useful?
comment:4 Changed 11 years ago by
Status: | pending → new |
---|
These changes are useful for the same reasons as #9800, only moreso.
We already implement the stack operations, but their naming and use is haphazard. Consistent terminology will support predictable and intuitive understanding.
Example: Instead of $elements.andSelf()
as a shortcut for $elements.add( $elements.end() )
, we have $elements.addBack()
as a shortcut for $elements.add( $elements.back() )
.
The depth parameters could be dropped (and I'd still support these changes even if they were), but they are an obvious modifier to the "back" operation: how far back?
Example:
// highlight matching definitions and their corresponding terms, // skipping non-matching definitions of the same term jQuery( "dd", context ) // all <dd>s .filter( matches ) // matching <dd>s .prevUntil("dt") // intervening <dd>s .addBack() // all <dd>s for matching <dt>s .prev("dt") // matching <dt>s .addBack(2) // matching <dd>s plus their <dt>s .each( highlight ); // add styling/data/listeners/etc.
comment:5 Changed 11 years ago by
I like the idea of renaming .andSelf()
to something more logical, which is also proposed in #9800, and the .addBack()
name is better than .andPrior()
IMO, especially since we are truly adding things to the set.
On the rest, I don't see a compelling reason to add anything. There may be things you want to do to a generic stack that aren't commonly needed for our chain of jQuery .prevObject
s. I agree these let you do more things with chaining, but they aren't things people have clamored to do over the past five years.
comment:6 Changed 11 years ago by
Resolution: | → plugin |
---|---|
Status: | new → closed |
It doesn't sound like there's a lot of enthusiasm for adding these to core, although #9800 remains open for the rename of .andSelf()
.
The "jQuery chain" is functionally a singly linked list, not a stack.