|
I target 3.5 .... coz ... 
i need WPF!!!
When I was born, I was so surprised I didn't talk for a year and a half.
|
|
|
|
|
But, did you *need* WPF before the existence of WPF, what could you be doing if the existance of WPH never came.....? 
|
|
|
|
|
I have to target 2.0 - but I play around with 3.5. LINQ is a really good feature. It will become outstanding when the promised support for various databases besides SQL can be accessed (here, it's useful to be able to connect to FoxPro and Excel at times).
Just for fun, when I was first using LINQ, I used two comboBoxes as though they were table in a database: running SQL-ish queries against their data, creating joins, sorts, etc., with no sweat.
If I could add LINQ to my other-users software, I would do so in a heartbeat. Buying into MicroSloth made me rather uncomfortable - but it really is a fine extension.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Balboos wrote: I have to target 2.0 - but I play around with 3.5. LINQ is a really good feature. It will become outstanding when the promised support for various databases besides SQL can be accessed (here, it's useful to be able to connect to FoxPro and Excel at times).
by the way: linq is not only about databases (what is called DLinq anyway) but also about any datasource. this also includes in-memory objects. this is what my team is using linq for at most. most of the foreach-loops where replace with a simple linq-method call.
eg.
int myZipCode = 55455
var filteredCustomers = customers.Where(customer => customer.Zip == myZipCode);
...
try to use linq for your in-memory data / objects - its really cool and efficient.
|
|
|
|
|
You should have read the rest of my post: using comboBoxes as data sources is using memory objects. I also combined these, (as a more advanced exercise and discovered some limitations) with dBase queries. The only linq version I didn't do much with is XLINQ.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
sorry, didn't get this one 
|
|
|
|
|
I haven't found a single reason to use Linq yet. It doesn't seem to do anything that you couldn't do before and only seems to be a syntax shortcut more than anything else to provide ways to do things you shouldn't or wouldn't do in real life.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
John C wrote: syntax shortcut more than anything else
That's all it was designed for. It's just designed to take away the work from you, sure you could create an ORM and then implement the delay-loading or whatever they call it but how does that saying go, why bother writing it when someone else has? (Or words to that effect).
John C wrote: things you shouldn't or wouldn't do in real life.
Since I'm feeling particularly dumb at the moment (been working away from the finesse of software and using sledge hammers on Land Rovers) can you explain?
|
|
|
|
|
Ed.Poore wrote: It's just designed to take away the work from you, sure you could create an ORM and then implement the delay-loading or whatever they call it but how does that saying go, why bother writing it when someone else has?
Well I find it harder to read for one thing but ultimately we have a lot of code written already and I can't see how jamming this in would affect that positively. Going forward on the next big thing I might have a look at it when it's matured more.
Ed.Poore wrote: Since I'm feeling particularly dumb at the moment (been working away from the finesse of software and using sledge hammers on Land Rovers) can you explain?
I was thinking of the example someone gave somewhere else in this thread where they were querying the contents of two combo boxes at the UI using LINQ to affect some kind of change. That just screams bad design principles. I never thought of doing stuff like that with it and now I can see all sorts of abuse and misue potential with it now that I've seen that example.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
John C wrote: Well I find it harder to read for one thing
Depends, I know SQL and find it easier to read than the equivalent code. Unless it gets convoluted and you're trying to perform lots of operatings in a LINQ expression then I agree it'd be easier to separate it out a bit.
John C wrote: we have a lot of code written already and I can't see how jamming this in would affect that positively
That's fair enough, if you've already got a code-base that does the same thing as LINQ then there's no point in using it.
John C wrote: I was thinking of the example someone gave somewhere else in this thread where they were querying the contents of two combo boxes at the UI using LINQ to affect some kind of change
That kind of thing is possible anyway, just because it's using LINQ doesn't mean LINQ's a bad thing. Any kind of technology has the potential for abuse.
|
|
|
|
|
Ed.Poore wrote: That kind of thing is possible anyway
Possible but not at all easy in the example of querying data stored in a combobox. I'm not knocking LINQ just backing up my statement that it makes it possible to do things you previously couldn't or shouldn't do.
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
I see you point but all technology fails in that respect. Still that's the whole point of this site, making developers better. 
|
|
|
|
|
John C wrote: It doesn't seem to do anything that you couldn't do before
That could be said about a lot of things - like C#, C++, etc. Once upon a time, C++ was 'compiled' as a first step by conversion to C. Thus, nothing in C++ is, by your argument, of interest viz-a-viz C.
Or, as was put by King Solomon (under one of his pseudonyms): "Everything which can be done has been done; Everything which can be said has been said; And there's nothing new under the sun."
Spreadsheets? We don't need no stinkin' spreadsheets! Where's my ledger paper and pencils. Bring me an eraser! Wordprocessors? Typewriter and some cut-and-paste for graphics (real scissors, real rubber cement), for after all, graphic design to accompany text has been around for a while. Spelling checkers were large hunks of paper-sheeting called dictionaries. Who needs shortcuts?
Actually, you hit it right on the head: it's a syntax shortcut: and the enormous nested if-(and other)
blocks I'd need to duplicate it are well worth short-cutting.
I'm generally behind the curve on new stuff - especially development tools - as they come out (it seems) daily. LINQ has extraordinary potential and a short-ish learning curve (to start).
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
Time will tell I guess and I'm sure I'll be using it some day if it matures and sticks around long enough but right now we're not doing any new development as we have a number of existing applications we are supporting and adding new features here and there over time. I can't see any reason to try to shoehorn it in when it effectively does nothing I'm not already doing but imposes the penalty of requiring the .net 3.5 runtime when many of our customers probably don't have it and I don't want to force them to do anything they don't absolutely have to do, it's like herding cats. 
"It's so simple to be wise. Just think of something stupid to say and then don't say it."
-Sam Levenson
|
|
|
|
|
Presently, we're targeting v2.0, mainly because IT hasn't approved v3.5 for use on the webservers yet. We have a major new feature release to the website planned for the coming months (we turn it over to QA in August; go live should be in September) so we should be upgrading after that.
Truth,
James
|
|
|
|
|
Hmmmm.... my first thread, and it has come a long way  .
|
|
|
|
|
3.5 as I only create applications for internal use.
|
|
|
|
|
I think the only thing that determinates which version is the target market. If we target small specjalized group of users we can force them o move to any version we need - we can force them to do almost anything . But if the target is global then we need to consider many things like: OSs used, download speeds, client mashine speeds. In many cases 2.0 or 2.0sp1 is sufficient.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
