|
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"
|
|
|
|
|
I do have first hand experience dealing with 3rd party that sits between my customer and me. It is very similar.
This customer has outsourced insurance verification for contractors. At least that is how it started out.
Then they added verification of quality control procedures, then they added verification of training procedures, and so on and so on.
Their current mission is:
.... is an online contractor and supplier management platform of data-driven products and services that help manage risk, support sustainability and strengthen relationships. It helps reduce unnecessary duplication associated with traditional qualification processes.
There is enormous scope creep to justifiy their existence.
The contractors are on the receiving end of overbearing rigidity, frequent requests to update procedures, and ever increasing requirements for insurance coverage, everything is cookie cutter style. You don't comply you get downgraded.
There is no longer a personal connection with the customer, that relationship was not strengthned.
The relationship with the customer is now only based on a grade for how well you comply with the procedures set in place by the company in between.
Every fad comes down the pipeline and is implemented.
The contractors hate this 3rd party.
The cost of compliance is sky-rocketing, and as a result the customer sees rapidly increasing cost.
I don't think your candidates will have a much different experience.
|
|
|
|
|
I don't think your candidates will have a much different experience.
Some nice thoughts here.
I actually don't mind my being the boss and the HR person as well - there are even advantages.
Just yesterday, because I addressed an issue head on, it took what could have been a contentious issue, de-escalated things and got everyone to a place where they understood the company position and came to a solid mutual understanding. An agency would not have been able to help with this and would have drawn the pain out and perhaps not gotten it to a solution.
"Qulatiy is Job #1"
|
|
|
|
|
good luck! Just know that the quality of treatment of individuals goes down when they are called resources. Instead of say by their NAME!
Maybe call it personal coordinator or something instead of HR.
My .02
To err is human to really elephant it up you need a computer
|
|
|
|
|
And remember that nowadays these people are more woke than anyone else. Whatever that means.
These days I have more contempt for HR than sales or even marketing...good thing I'm working for a tiny company that has no need for an HR department.
|
|
|
|
|
Good point @dandy72, about them being more woke than anyone else.
They are out to change the world, including your world.
Whether you like it or not.
As an illustration the 3rd party I am dealing with all of a sudden disallowed the section of our Health, Safety, and Environment manual, because....... tada.....we could no longer use the terminology of MSDS (Material Safety Data Sheets). Stern words accompanied this edict: "only in a historical context".
Turn out there is a UN program that is being pushed and we are all now supposed to use SDS (Safety Data Sheets).
To the OP my recommendation is to keep things simple, and have someone you know and trust handle this for you.
|
|
|
|
|
To the OP my recommendation is to keep things simple, and have someone you know and trust handle this for you.
My wife? 
Sounds like another vote against an agency....
"Qulatiy is Job #1"
|
|
|
|
|
rnbergren wrote: the quality of treatment of individuals goes down when they are called resources
William Shakespeare (almost) wrote: Hath not a Resource eyes? Hath not a Resource hands, organs, dimensions, senses, affections, passions? Fed with the same food, hurt with the same weapons, subject to the same diseases, healed by the same means, warmed and cooled by the same winter and summer, as a Manager is? If you prick us, do we not bleed? If you tickle us, do we not laugh? If you poison us, do we not die? ...
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
