|
OriginalGriff wrote: Anyone else got the same?
Well, kinda: I see a jigsaw puzzle when I look in a mirror 
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
 What happened?
Did you cut yourself shaving with a cut-throat razor? Prurient minds want to know... 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
No, I gave up shaving after the pieces with beard on them started moving around at random
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
So the Sky really is falling?
I’ve given up trying to be calm. However, I am open to feeling slightly less agitated.
|
|
|
|
|
This happened to me about 1 year ago now. Internet down. Cell phones down. Big storm knocked everything off line. And I had to do an interview (virtual) for a new job.
Ended up driving to a place with cell phone coverage and doing the interview from my hotspot in my vehicle. and I got the job.
Crazy huh.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Yes; she also likes the puzzles.
A fibre optics line was run through my front yard just this week. All I have to do is tell them to "switch it on" if and when I switch from my current ISP / cable (which currently seems fast enough).
It was only in wine that he laid down no limit for himself, but he did not allow himself to be confused by it.
― Confucian Analects: Rules of Confucius about his food
|
|
|
|
|
I am from New Orleans, and right now all things are down, starting with electric power, thanks to Hurricane IDA. I evacuated to a hotel in Gulf Shores, Alabama, where I am now.
I'd trade problems with you, if it were possible. 
ed
|
|
|
|
|
Around a luxe conference table, in a room with a large window offering a view of a manicured garden with trees and flower beds, on a late spring day, when the Pacific Northwest's lust for wet and drizzle had not subdued the sun, in Redmond:
PM Program Manager
Dv1 Developer 1 wpf team
Dv2 Developer 2 winform team
Dv3 Developer 3 core team, xamarin team
PM: "Okay, the team working on windowsbase.dll has some exciting news to share ... over to you Dv1:"
Dv1: "Thanks, I'm really jacked-up today, and, not just from Red Bull (laughter); we've finished regression testing on the new Point, Vector, and Rect classes for WBD: performance is excellent, with low memory footprints at 500k+ instance scales ... even at only 16 gigs of memory."
(Applause)
PM: "Issues ?"
Dv2: "'Point:' that's a name collision with WinForms !"
Dv1: "uhhh ... we've never heard anything about using WBD with WinForms ... uhhh ... that's not in the spec ... uhhh ... is it supposed to be used in WinForms ?"
PM: "Who wrote the spec ?"
DV1: "... uhhh .... that would be the WPF team, and, since the cutbacks in the WPF and WinForms teams, we haven't had the kind of exchanges ..."
PM: "We can stop right there; we're not here to discuss staffing. What is the worst possible case here ?"
Dv2: "... well, a WinForm dev with a big app makes a lot of use of System.Drawing.Point ,,, then, he references WBD ... everything breaks ... the old ambiguity name clash TKO ..."
Dv1: "What's 'TKO' ?"
Dv2: "... 'Technical Knock Out' ... a boxing thing."
PM: "Can we stay on track, here, and not use acros that are not MS' acros ?"
DV3: "... well at Ms, 'TKO' could well stand for 'technical knowledge oversight' ..."
PM: "Enough already ! What's the fix ?"
Dv1: "well, make it work only in WPF, Core ... "
Dv2: "not a good idea; winform devs want to use these new structures."
Dv3: "just finesse it ? tell winform devs to use WBD in namespaces where they don't reference System.Drawing ?"
Dv2: "not good ... that means a winform dev with a big app may have to do a humongous re-write."
Dv1: "Is it really so bad ? I mean you start with a big app that does not make use of WBD, you replace every instance of 'Point' with 'System.Drawing.Point' ... you're good to go."
DV3: "imho, any global search and replace on a big app is ... suboptimal."
Dv2: "Isn't the real solution to rename Point in WBD so it doesn't clash with System.Drawing ?"
Dv1: "... not happening !"
A moment of silence.
PM: "Would the WPF team enjoy the cost of re-testing, and the cost of handling dev support when their apps break ... because 'Point' doesn't work any more in apps using WBD ? ... taken out of their next-year budget ? ... would the WinForms team like to share the cost ?"
A silence.
PM: "Excellent, I'm upping status to golden master, and, on that happy note, meeting's over."
Dv1 looked up from his Surface G0, where he had been tying notes: "Hey ... wait a minute ... I forgot about 'Size' ... that's another ..."
Before Dv1 could reach the end of his sentence, he noticed the room was ... empty.
~ postscript
I am rewriting a WinForm geometry library to use the new WBD structures. I am using these "expedients," at present, in namespaces where both library-flavors of Point and Size are used.
using SdPoint = System.Drawing.Point;
using SwPoint = System.Windows.Point;
using SdSize = System.Drawing.Size;
using SwSize = System.Windows.Size; Eventually, I will evaluate the cost of isolating the code so name clashes are avoided, while still using the "native" names.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 2-Sep-21 3:15am.
|
|
|
|
|
I'm shocked. This is the kind of thing that should never happen, and certainly not with components built by the same company.
Even Microsoft must have heard of the idea of having a single owner of a namespace, with additions / modifications to the namespace being made only with his/her permission. I assume that the maintainer of the System namespace was fired in the name of "efficiency". 
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Hi Daniel. Well, at least they did use'Rect and 'Vector in windowsbase.dll, which are unique
cheers, Bill<
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
But isn't that the whole point of namespaces? Two classes can happily have the same name, so long as they're in different namespaces.
If they'd given both sets of classes the same namespace, then that would be a whole world of pain.
extern alias - C# Reference | Microsoft Docs[^]
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Hi Richard,
Perhaps I am not understanding your comment: imho, this issue arises not at the level of app NameSpace scope, but only when:
1) the WinForm Project references both System.Drawing, and (after installing windowsbase.dll) System,Windows ... and prefaces the app NameSpace with the appropriate using statements.
2) any use of the "unqualified" names 'Point, or, 'Size will then cause compile time errors.
I think I may have made a finer distinction than necessary between using invocations, and app namespaces.
cheers, Bill
p.s. long ago, when I had my fifteen minutes of fame in the PostScript domain, I really enjoyed the explicit use of a Stack of Dictionaries to determine semantic meaning in context, and the parallel Stack of global Graphic States you could manipulate with 'gsave, 'grstore, etc. [^]
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 2-Sep-21 5:31am.
|
|
|
|
|
My Point was that this is normal; if two classes in different namespaces have the same name, and you use both namespaces, then you'll end up with ambiguous references.
If you start with a class that uses System.Drawing and has unqualified references to Point and Size, then the simplest option is to add aliases for the System.Windows types, and use those in the new code you're writing.
It's slightly annoying, but there are only so many words you can use to describe a class that represents a point or a size. If every new library that exposes those concepts had to come up with a different word for the same concept, that would be a worse outcome than having to alias the types in the unusual places where both are used.
But at least the types are in different namespaces, so you don't need to mess around with extern aliases for the assemblies.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
It would be interesting to know if this issue came up in defining the windowsbase.dll code. I'd wager 60/40 odds it is something slipped through the cracksRichard Deeming wrote: It's slightly annoying, but there are only so many words you can use to describe a class that represents a point or a size. If every new library that exposes those concepts had to come up with a different word for the same concept, that would be a worse outcome than having to alias the types in the unusual places where both are used.
I must respectfully disagree: if they go to the trouble of using 'Rect instead of 'Rectangle, why re-use 'Point, and 'Size, and cause an unnecessary work-around ? For me, that is the worst outcome Richard Deeming wrote: If you start with a class that uses System.Drawing and has unqualified references to Point and Size, then the simplest option is to add aliases for the System.Windows types, and use those in the new code you're writing.
That's exactly what the work-around I show in my first post does, and, when you are dealing with code that uses both libraries, it's a pain in the butt.Richard Deeming wrote: But at least the types are in different namespaces, so you don't need to mess around with extern aliases for the assemblies.
Interesting, thanks, I will look into the usage of 'extern.
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
BillWoodruff wrote: if they go to the trouble of using 'Rect instead of 'Rectangle, why re-use 'Point, and 'Size, and cause an unnecessary work-around?
I'm guessing that Rect came from the C++ type RECT:
RECT (windef.h) - Win32 apps | Microsoft Docs[^]
For Point and Size, I'm guessing the equivalent C++ types already had those names. There aren't really any suitable abbreviations that could be used. Having each library use a different synonym would be quite confusing, especially for non-English devs - Point/Size in one, Locus/Dimension in another, Position/Magnitude in a third, etc.
Imagine if you had to apply that across the board - You can't call your customer class Customer because that name has already been used in a different project; have you considered using Punter instead?
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
On this issue, I am afraid our hypotheses will remain mutually incompatible Richard Deeming wrote: Having each library use a different synonym would be quite confusing, especially for non-English devs
I assert the way it is now is potentially confusing to all devs.
You might frame the issue as arising from: "they were thinking in C/C++;" I'd say: "arising from some mixture of: absence of thinking, poor co-ordination, lack of oversight."Richard Deeming wrote: Imagine if you had to apply that across the board - You can't call your customer class Customer because that name has already been used in a different project; have you considered using Punter instead?
Thanks for that absolute howler of a non-sequitur !
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
In this case I'd let VS warn me about the ambiguity and go fix the issues. This is the entire purposes of namespaces in the library.
|
|
|
|
|
I just showed you one way to fix the possible name-clashes, and, so, you suggest I "fix the issues" ?obermd wrote: This is the entire purposes of namespaces in the library.
Their purpose is to make the developer write work-arounds for their flawed implementations ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
modified 3-Sep-21 10:42am.
|
|
|
|
|
Message Closed
modified 2-Sep-21 5:20am.
|
|
|
|
|
I think this reply was meant for the message above.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
They did something similar with:
System.Data.SqlClient
Microsoft.Data.SqlClient
|
|
|
|
|
inconsistency is everywhere: it looks back at me in the mirror
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
Sounds like an excellent decision by technical management at Microsoft. Yes, why bother doing a simple rename of the specific API namespace when so much more fun could be had working out the many expected complaints between the two development environments?
Oh well, it is good to see that technical management idiocy in the US is still alive and well.
At least it is consistent...
Steve Naidamast
Sr. Software Engineer
Black Falcon Software, Inc.
blackfalconsoftwareoutlook.com
|
|
|
|
|
In my experience, seeing consistency in code syntax across domains, or lack of needless duplications of functionality/code ... would have been a surprise
Maybe there's a trade-off here ? If you have one "code czar" (like Stroustrup, Torvalds ?), or one "star chamber," with strong oversight ... you get more consistency, but, perhaps, slow down, or even stifle innovation ? And, if you have the grows by accretion, by accident, model, with multiple teams who don't coordinate, by survival of the fittest, by catering to the desires of groups of users with different usage patterns ... you get today's C#, or, PhotoShop ?
I'm not trying to blame developers here The pressures in the context that frame what devs can do, or have time to do, are often coming from top-down as program managers respond to marketing demands, as "feature races" drive budget allocations, as corporate execs respond to shareholder demands.
In other words, it's a mess, just like life ?
«The mind is not a vessel to be filled but a fire to be kindled» Plutarch
|
|
|
|
|
This is a funny place to be asking this, but I assume there are a fair number of business folks in the Lounge, so perhaps I'll find a gem of an answer here.
We are a 25 person development company. We have always had a very flat structure with me as the CEO/founder being the de-facto HR manager. Now, I am thinking it is time to hire an HR group to be a repository to answer all HR questions.
- Does anyone have a suggestion for a solid outsourced HR group to help manage this for their company?
- What pitfalls should I look out for using an outsourced HR group?
- Would I be better to hire an individual for this specifically?
Thanks in advance!
David
"Qulatiy is Job #1"
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
