I'm used to dynamic typing meaning checking for type info of object/non object oriented structure at runtime and throwing some sort of type error, ie if it quacks like a duck its a duck. Is there a different type of dynamic typing (please go into details).
Yes, absolutely. Duck-typing is an idiom which says that the type of a value at this moment in time is based on the fields and methods that it has right now. Dynamic typing just says that types are associated with run-time values, not with static variables and parameters. There is a difference between the two, and you can use the latter without the former.
For example, if you programmed in PHP and limited yourself to the basic types without using OO, then you would be using dynamic typing without using duck-typing.
No, dynamic typing is when values have type but variables do not, so most type checking is done at runtime. So, basically, if the value walks or quacks like a duck, it's a duck, else an error is thrown. Duck typing really just describes a feature of dynamic typing that ensures it will be typesafe (i.e. a method will only run if variable foo'has the right attribute or can execute that method).
Related
Can anyone actually explain, in layman's terms, what is a real-world use case for the set operation's options?
While I fully understand what set with merge does, as well as merge beeing a boolean and mergeFields being an array of fieldPaths, I cannot think of cases in which mergeFields might be of any use.
I also understand the fact that mergeFields basically acts like a mask for the object passed to the set operation, but I still cannot think of how is it so useful that it actually got implemented within the SDK.
Can someone shed some light?
After looking through the documentation, there seem to be two reasons why you might want to use one vs the other:
mergeFieldPaths/mergeFields trigger an error when passing in field values that don't currently exist on the document while merge will add in those fields if they don't exist. The error is good for safety purposes if you're concerned about typos/writing to incorrect field paths.
This one is just a guess, but the documentation indicates mergeFieldPaths/mergeFields ignores AND leaves fields untouched while merge ONLY leaves other fields untouched. It's possible there's some performance advantage to using mergeFieldPaths/mergeFields esp for documents with a ton of fields. The difference might be direct access vs still needing to look at unspecified fields to identify the matches in some way.
SetOptions Reference
I am trying to pass variables from one page to another using Sessions , but they don't seem to have effect. In the source page inside the razor syntax
Session["variable"] = "value";
And in the target page:
<p>#Session["variable"].ToString()</p>
but I get a server error
Exception Details: System.NullReferenceException: Object reference not set to an instance of an object.
Any suggestions would be most welcome........Thanks
I was only ever able to get this to work with casting:
<p>#(string)Session["variable"]</p>
Although it has been a long time since I have tried it with ToString() instead, I do explicitly remember my attempt to call a Session variable only successful with the casting option, although I have heard that ToString() should work. Either way, I always get it to work with casting.
That having been said, I feel it only right of me to warn you that if you are simply trying to pass data between pages, you shouldn't be using Session variables at all. Use hidden form fields, query strings, Url Data, or even cookies and/or databases before you do that.
I like to look at Session variables as something to quickly solve very special cases and only to be used very CAREFULLY. ALWAYS expect the value to be null and test its value before using it.
For help with the options for transferring data between web pages using WebMatrix, check out Mike Brind's very helpful site: http://www.mikesdotnetting.com/Article/192/Transferring-Data-Between-ASP.NET-Web-Pages <-- You'll want to bookmark this for now. It is right up the alley of what you are getting yourself into with WebMatrix.
If you still want to use the Session variable and casting doesn't work, the only other thing I can think that would cause the error is that the value you expect in Session["variable"] isn't what you think it is.
For the Record:
I was only trying to make a point when saying, "or even cookies and/or databases before you do that" Please do not use those options, as they are likely terrible in your case (also, cookies would just give you the same problems as Session variables, actually). In any case, it really all depends on how you are using the data and if you are always checking to make sure the value hasn't been cleared in the case of Session variables and/or cookies.
Question:
Is there a static way to reliably determine the type contained by a type derived from CollectionBase, using Reflection or Microsoft.Cci?
Background:
I am working on a code generator that copies types, makes customized versions of those types, and converters between. It walks the types in the source assembly via Microsoft.Cci. It prints out source code using textual templates. It does a lot of conversion and customization, and tosses out code that I don't care about.
In my resulting code, I intend to replace List<T> everywhere that a CollectionBase, IEnumerable<T>, or T[] was previously used. I want to use List<T> because I am pretty sure I can serialize it without extra work, which is important for my application. T is concrete in every case. I am trying not to copy CollectionBase classes because I'd have to copy over the custom implementation, and I'd like to avoid having to do that in my code generator.
The only part I'm having a problem with is determining T for List<T> when replacing a custom CollectionBase.
What I've done so far:
I have briefly looked at the MSDN docs and samples for CollectionBase, and they mention creating a custom Add method on your derived type. I don't think this is in any way enforced, so I'm not sure I can rely on that. An implementor could name it something else, or worse, have a collection that supports multiple types, with Object as their only common ancestor.
Alternatives I have considered:
Maybe the default serialization does some tricks that I can take advantage of. Is there a default serialization for CollectionBase collections, or do you generally have to implement it yourself? If you have to do it yourself, is there some reliable metadata I could look at in order to determine the types? If it supports default serialization, does it rely on the runtime types of the items in the collection?
I could make a mapping in my code generator of known CollectionBase types, mapped to their corresponding T for List<T>. If a given CollectionBase type that I encounter isn't in the list, throw an exception. This is probably what I'll go with if I there isn't a reliable alternative.
I'm still not sure enough about what you want to do to give advice. Still, do your CollectionBase-derived classes all implement Add(T)? If so, you could look for an Add method with single parameter of type other than object, and use that type for T.
Let's say I'm creating some app documentation. In creating a content type for functions, I have a text field for name, a box for a general description, and a couple other basic things. Now I need something for storing arguments to the function. Ideally, I'd like to input these as key-value pairs, or just two related fields, which can then be repeated as many times as needed for the given function. But I can't find any way to accomplish this.
The closest I've gotten is an abandonded field multigroup module that says to wait for CCK3, which hasn't even produced an alpha yet as far as I can tell and whose project page makes no obvious mention of this multi-group functionality. I also checked the CCK issue queue and don't think I saw it in there, either.
Is there a current viable way of doing this I'm not seeing? Viable includes "you're thinking of this the wrong way and do X instead." I've considered using a "Long text and summary" field, but that smells hackish and I don't know if I'd be setting myself up for side-effects. I'm new to Drupal.
There is the http://drupal.org/project/field_collection module but it's not yet ready. Right now you would need to implement your entity alas to do this :( not easy.
Not sure how well it would work, because it currently does a bit more (eg, forces to group pairs into categories and the keys need to be predefined) but you might want to have a look at http://drupal.org/project/properties.
You could create a these key-value fields on their own: create 2 regular fields that that can be added as often as needed.
So you have a x fields for the keys and x for the values. If this is only for you or other people it might work OK but usability wise, it's very ugly.
If you need to extract the fields from the function, to display it properly in a page template, you should propably use a different approach. Write the function with its arguemnts in a CCK field and in the template extract them as needed. The arguments are always (depending on language) in () and the different arguments are seperated by , so splitting them would by pretty easy.
Because I rush in development (a lot of whip cracking here) and declare my objects at the top of the function and instantiate inside my try-catch block, I get a lot of the good old "object not set to an instance of an object" errors while doing TDD, and later if I do miss a branch that object was used in (doing VB now, would prefer C#) or just in every day coding, object not set to an instance of an object is a bit vague. Sure the stack trace sends me to the line the error occured at, but it would be nice if I could modify my logging to either name the object or its type because sometimes I have multiple objects on the same line. It's not the end of the world, but in the end it would save me a few minutes each day. Any ideas on how I can pass the info on which object wasn't set? Thanks
It is non trivial to "modify your logging" to output variable name or type - I am sure that if the framework could easily get this information from the executing IL, MS would have included it the null reference exception.
Prevention is always better than cure. Here are a couple of tips I would do
Fix your compiler warnings
C# would generate a compile error if it detects that there are code paths that could use an unassigned local variable. [For some odd reason] VB.Net will still compile but the compiler will generate a warning - take heed of these and go and fix the code and you should never run into the problem of unassigned variables again!
Adopt a different coding pattern for variable declaration
I appreciate that method variable scope in ye olde VB was that the variable was visible throughout the entire method regardless of where it was defined. As a result, it was a reasonable practice to put all your var declarations at the top of the method. VB.Net of course is different - you can only use variables after they are declared and so it is OK (and I would say preferable*) to put the declaration (and assignment) closer to where the variable is actually used. This should help you see "by eye" if your program logic means it is possible to use an unassigned variable.
Some people think this is a think that it is always good practice to put variable declarations in a block at the top of the method. I will not argue against them but I would say that that approach works best with small methods that do not use lots of variables.