Quick question which I fear has a short and disappointing answer but alas I shall ask anyway..
In the C++ Dictionary method TryGetValue() is there any way to change the default value that will be returned for an integer (to -1 instead for example) when the key is not present? The problem is that 0 is the default and this is not suitable because a value of 0 would make sense in the context of my program.
If not, is the ContainsKey() method that much slower? Or is it splitting hairs and nothing to worry about seeing as in all likelihood I have no choice..
Many thanks
PS I don't need to perform any hashing function (though this might be in the implementation for Dictionary anyway!), nor have any particular ordering to my collection, I just want lookup and adding to be as fast as possible. Is Dictionary a sound choice?
Why don't you create a class that inherits from Dictionary(Of TKey, TValue) and override the TryGetValue function. You could then use your own class and it would behave just as you would want it to...
Related
I am trying to make a replacement VB6 class for the Scripting.Dictionary class from SCRRUN.DLL. Scripting.Dictionary has (among other things) a "Keys" method that returns an array of keys, and a read/write "Item" property that returns the item associated with a key. I am confused about this, because both of them seem to be defaults for the class. That is:
For Each X In MyDict
Is equivalent to:
For Each X In MyDict.Keys
Which to me implies that "Keys" is the default operation for the class, but:
MyDict("MyKey") = "MyValue"
MsgBox MyDict("MyKey")
Is equivalent to:
MyDict.Item("MyKey") = "MyValue"
MsgBox MyDict.Item("MyKey")
Which to me implies that "Item" is the default operation for the class.
I've never before created a VB6 class that had a default operation, so upon realizing this, I thought perhaps I could define multiple default operations as long as they all have different signatures, which they do: Keys is nullary, the Item getter takes a Variant, and the Item setter takes two Variants. But this doesn't seem to be allowed: When I use "Tools/Procedure Attributes" to set the Keys function to be the default, and then I use it to set the Item property to be the default, the IDE complains that a default has already been set.
So I think I'm misunderstanding something fundamental here. What is going on in the Scripting.Dictionary object that makes it able to act as if "Keys" is the default in some contexts, but as if "Item" is the default in others? And whatever it is, can I accomplish the same thing in VB6?
OK, answering my own question: I haven't tried this yet, but I gather that "Item" should be made the default, and that I should add an entirely new function called "NewEnum" that looks something like the following (slightly modified from an example in Francesco Balena's "Programming Microsoft Visual Basic 6.0" book):
Public Function NewEnum() As IUnknown
Set NewEnum = m_Keys.[_NewEnum]
End Function
(where "m_Keys" is a Collection containing the keys), and then use Tools/Procedure Attributes to hide NewEnum and to set its ProcID to -4.
What you are observing is the difference between the default member and a collection enumerator. A COM object (including VB6 classes) can have both.
You can identify the default property of a class by looking in the Object Browser for the tiny blue globe or the words "default member of" in the description (see Contents of the Object Browser). The Object Browser will not identify an enumerator method, but if you look at the class's interface definition using OLE View or TypeLib Browser (free but registration required) it's DispId will be 0xfffffffc or -4.
In your own class, you can mark the default property by setting the Procedure ID to "(default)" in the Procedure Attributes dialog (see Making a Property or Method the Default). You already listed the steps for setting up the collection enumerator in your own answer, but you can find this listed as well in the Programmer's Guide topic Creating Your Own Collection Class: The House of Bricks.
Scripting.Dictionary has a dirty secret:
It does not handle enumeration at all, it returns big ugly Variant arrays and your For Each loops iterate over those.
This is one of the reasons why a Dictionary can actually be far less efficient than a standard VB6 Collection.
Can anyone tell me what is the main advantage of using tuple? In what scenarios do I need to use these?
I assume that you're talking about the Tuple<> type and not anonymous tuple classes.
Like an anonymous type, Tuple<> allows you to avoid declaring a new class just to group a few objects. Unlike anonymous types, tuple types have known names and thus can be used as method return and parameter values, etc.
Personally, I try to avoid heavy use of Tuple<> because it can make for difficult to understand code, expecially when used with primitive types (e. g. if you see a Tuple it's not obvious what each field represents).
One place I have found tuples to be very useful is as dictionary keys. Because Tuples implement Equals() and GetHashCode() (not ==, though!), they are perfect for things like private dictionaries that cache information based on a compound key.
It's used mostly to avoid declaring a class / struct with a few properties only for the sake of passing a group of objects around, where only one object can be passed.
Lets say I have a list of urls to go through and if i get an error (4xx or 5xx) I want to build a list and then either later display it to the user or just look at it in my debugger.
I'd catch the web exception and have a Tuple<string, int> (url, http error code) instead of creating a struct for one or two functions to use. Heck it might even be a foreach loop with a breakpoint on if the list has more then 0 items. Thats when it is useful.
I have the code in one of my flex file used as labelFunction in a DataGrid.
When I run the FlexPMD to do the code review, it generates an objection about the dynamic type object used in the following method signature and it suggests to use strongly type object.
public function getFormattedCreatedTime(item:Object, column:DataGridColumn):String {
var value:Date=item[column.dataField];
return dateFormatter.format(value);
}
Does anyone know how to rectify it?
Thanks
You have the answer in your question - just use a strongly type object, or perhaps an interface if item can have various types.
But basically there's nothing wrong with using dynamic type objects as long as you know what you're doing. I'd say just ignore the error.
In this case it would be of course possible to type item to something less generic than Object, but some times you can't, or Object is exactly the right type, in this case you can use //NOPMD comment - it will instruct the PMD validator to skip the definition. Of course the good practice is to also explain the reason you used //NOPMD.
What is the best way to provide strongly typed access to the session object? I am planning on turning on Option Strict, which is causing the compiler to complain about my lazy programming technique of directly accessing the session object:
Dim blah As Integer = Session("Blah")
My initial thought is to create a class that wraps the session and provides strongly typed properties for the information stored in the session. However, I cannot decide if the class should be a singleton, or instantiated on every use, or where the code should reside (i.e. within the web project or within a class library).
I'm leaning towards a singleton in my class library, but I don't know if that is the best solution, or if I am missing any other possibilities.
Proposed Solution:
Public Class SessionAccess
Public Shared Property Blah(ByVal session As HttpSessionState) As Integer
Get
Return Convert.ToInt32(session("Blah"))
End Get
Set(ByVal value As Integer)
session("Blah") = value
End Set
End Property
End Class
Code Behind:
Dim blah As Integer = SessionAccess.Blah(session)
I deleted my original answer as #Jason Berkan made a very good point when he questioned my answer. Jason, I think this idea is fine.
The only thing I would change in your code example is to check to ensure that the session variable exists.
Either my proposal is the "standard" way to do it, or else no one wraps their session access, since this question hasn't received very many answers.
I did find one line in this answer that mentioned creating a SessionManager:
Wrap the ASP.NET Session with a
SessionManager to avoid development
mistakes in spelling, etc. when
referencing items from Session.
I have not thought of any reason to not use a singleton class to provide typed access to the session, so that is the solution I went with in the project.
When using .contains() on an ArrayCollection in Flex, it will always look at the memory reference. It does not appear to look at an .equals() method or .toString() method or anything overridable. Instead, I need to loop through the ArrayCollection every time and check each individual item until I find what I'm looking for.
Does anyone know why Flex/ActionScript was made this way? Why not provide a way from people to use the contains() method the way they want?
Couldn't you just extend ArrayCollection and override the contains() method? Alternatively you can paste the source for ArrayCollection into an "mx/collections" package in your project and modify the source; this "monkey-patching technique" will override the behavior throughout your entire project. However I would be extremely cautious about changing ArrayCollection in that manner: since it's used all over the place in the Flex APIs there is a good chance you'll start breaking other components in the framework.
The contains() method searches by reference, correct (I believe even for primitives), so if you're trying to find a string or an int in an ArrayCollection, you'll have to do the searching yourself, by some variation of looping or searching. I don't think any of us could tell you why there isn't, say, an optional parameter on that method indicating whether to search by ref or by val, though; so it goes, as they say.
But I'd definitely warn you off monkey-patching the framework code -- that's just asking for trouble. :)
Well, it seems like the ArrayCollection doesn't actually look directly at memory, but only as a last resort. It will attempt to find a Unique ID (UID) for the object. If the UID doesn't exist, it will create one for it using the UIDUtil.as.
You can get around this whole default UID stuff by having your object implement the IUID interface and providing your own UID for the object. The ArrayCollection will look at the UID you provide it.
I would suggest a simple:
in_array($haystack, $arrayCollection->toArray());