An opinion on naming
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
Queue<t> itself conflicts
Not if you namespace it. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
-
honey the codewitch wrote:
Queue<t> itself conflicts
Not if you namespace it. :) /ravi
My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com
Yeah I did namespace it. Still, conflicting with Microsoft's class name irks me a little. I think it can get confusing and icky if you reference System.Collections.Generic in your usings, which is really common (and I think by default when you create a new C# file in a VS .net framework project)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
QueueCollection
Wrong is evil and must be defeated. - Jeff Ello
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
QueueCollection
Wrong is evil and must be defeated. - Jeff Ello
'cept it's a list. Collection doesn't guarantee order. List does, and provides indexed access, which my queue does. I'll consider QueueList, thanks
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
When Microsoft extend something they usually (well quite often) add the suffix Ex. So how about
QueueEx? Does it not show up in Reference Source[^]?They do that more in Win32 and COM than .NET Usually with .NET they just stick new objects under a new namespace and try to name them differently. :sigh:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
Oooh, I like that one. I'll definitely consider it. So far it looks like it might be a winner. :)
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
I wish Microsoft would have simply exposed the internal method they have in the reference source
Add an extension method and use reflection to call it. ;) Oh wait, you said efficient indexing. :laugh:
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX Calls -
honey the codewitch wrote:
I wish Microsoft would have simply exposed the internal method they have in the reference source
Add an extension method and use reflection to call it. ;) Oh wait, you said efficient indexing. :laugh:
Latest Articles:
16 Days: A TypeScript application from concept to implementation Database Transaction Management across AJAX CallsYeah, I was gonna say. Not only that, it's kind of terrible to rely on a non-public method in someone else's code.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That was my first thought as well. You beat me to it!
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
I need a replacement for Microsoft's Queue that allows for efficient indexed access to the items therein. So I made one. The trouble is, I don't know what to name it. By default, containers in .NET are implemented on arrays (like mine is) so since .NET 2.0 things like ArrayList have simply become (Implied Array)List - indicating array storage unless otherwise specified or there is no default array storage implementation (like with binary trees). The reason this comes up is because of things like LinkedList So while I'd name mine ArrayQueue that itself is inconsistent with microsoft's naming conventions post 1.x Queue itself conflicts but it's what it's currently named. I've made the interface compatible but put it under a different namespace. I'm kind of leaning toward this. Another option I considered was ListQueue because it provides indexed access, but that doesn't really jibe with microsoft's naming conventions either. To be honest, I wish Microsoft would have simply exposed the internal method they have in the reference source in order to provide indexed access. Seems silly that they didn't, since queues are ordered by definition, but whatever.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
From the top of my head.
public static T GetAtIndex(this Queue queue, int index)
{
T obj = default(T);
int count = queue.Count;
for (int i = 0; i < count; i += 1)
{
T temp = queue.Dequeue();
if (i == index)
{
obj = temp;
}
queue.Enqueue(temp);
}
return obj;
}I'm pretty sure that's how Microsoft intended it :D It's lightning fast if you have only a few items and you don't do it too often :laugh: Or you could do whatever you're doing an name it
IndexedQueue, like Greg also suggested.Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
From the top of my head.
public static T GetAtIndex(this Queue queue, int index)
{
T obj = default(T);
int count = queue.Count;
for (int i = 0; i < count; i += 1)
{
T temp = queue.Dequeue();
if (i == index)
{
obj = temp;
}
queue.Enqueue(temp);
}
return obj;
}I'm pretty sure that's how Microsoft intended it :D It's lightning fast if you have only a few items and you don't do it too often :laugh: Or you could do whatever you're doing an name it
IndexedQueue, like Greg also suggested.Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
That reorders the queue. I can't have my indexing have side effects. If I didn't have to worry about that your solution would be a decent one.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That reorders the queue. I can't have my indexing have side effects. If I didn't have to worry about that your solution would be a decent one.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
No it doesn't, you're simply dequeueing and requeueing everything, effectively ending up with the same queue. The only thing you do is grab the value when you hit the specified index ;)
honey the codewitch wrote:
your solution would be a decent one
NO IT'S NOT! It's de/requeueing EVERYTHING! X| I think Marc's reflection solution would be a better and faster one :laugh: It's also not thread safe, very thread unsafe even. You probably only thought it was decent because it was so beautifully written and formatted :rolleyes:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
No it doesn't, you're simply dequeueing and requeueing everything, effectively ending up with the same queue. The only thing you do is grab the value when you hit the specified index ;)
honey the codewitch wrote:
your solution would be a decent one
NO IT'S NOT! It's de/requeueing EVERYTHING! X| I think Marc's reflection solution would be a better and faster one :laugh: It's also not thread safe, very thread unsafe even. You probably only thought it was decent because it was so beautifully written and formatted :rolleyes:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I misread your code. I thought you were just enumerating until you found the item. Anyway, I'm not sure that would be faster. See based on what I know from the reference source, there's no reallocations taking place with your technique. It's just setting array elements and incrementing some integers. Reflection can be kinda nasty. I'd have to profile. It definitely depends on the number of items in the queue as well, but for what I'm currently using it for, it shouldn't be more than a half dozen to a couple dozen items.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I misread your code. I thought you were just enumerating until you found the item. Anyway, I'm not sure that would be faster. See based on what I know from the reference source, there's no reallocations taking place with your technique. It's just setting array elements and incrementing some integers. Reflection can be kinda nasty. I'd have to profile. It definitely depends on the number of items in the queue as well, but for what I'm currently using it for, it shouldn't be more than a half dozen to a couple dozen items.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
honey the codewitch wrote:
I thought you were just enumerating until you found the item.
That... Would be a lot easier, but I wasn't aiming for easy :D I also think the internal array doesn't shrink and regrow, so the impact shouldn't be too big. Internally, it keeps track of the head and the tail and wraps to 0 if the last index is occupied, but the array isn't full (it places the items in order when it does need to grow). Still, writing a wrapper, what you no doubt did, and keeping an internal array that you can use... Consumes twice the memory :~ Why the heck is my code a lot better than I originally thought :confused: Feel free to use it (at your own risk) :D Although I still think looping would be a bit faster, if only because you can break at the index.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
honey the codewitch wrote:
I thought you were just enumerating until you found the item.
That... Would be a lot easier, but I wasn't aiming for easy :D I also think the internal array doesn't shrink and regrow, so the impact shouldn't be too big. Internally, it keeps track of the head and the tail and wraps to 0 if the last index is occupied, but the array isn't full (it places the items in order when it does need to grow). Still, writing a wrapper, what you no doubt did, and keeping an internal array that you can use... Consumes twice the memory :~ Why the heck is my code a lot better than I originally thought :confused: Feel free to use it (at your own risk) :D Although I still think looping would be a bit faster, if only because you can break at the index.
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I did not wrap the queue. I implemented my own queue over an array, wrapping like Microsoft's class does.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I did not wrap the queue. I implemented my own queue over an array, wrapping like Microsoft's class does.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Yeah, that really seems the best, and most labor and time intensive method, for something so easy that could've been there at no extra effort :sigh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
