Sounds good to me . Im re-designing a new app right now where someone in India ( like a team of 30 ) decided to use Dependency properties in a base class , which all the business entities inherited from . The code passed all their test and the DLL runs in 2 different servers and a GUI client . Well I had a look closer and it turns out they limited the server to run on 1 thread processing requests sequentially. Take that out and run 1 request its fine run 2 request and i get threading errors from the WPF ( GUI lib) saying your not running on the GUI thread. Which is not surprising because dependency property is part of WPF (WindowsBase lib) should never be in a server and interacts with the GUI dispatcher.
Company wasted $12M on a piece of junk. Now is the relevant part , i cant easily re-factor this because there is 3000 references to the dependency property and base class methods that use the dependency property even though im sure 99% of the server code does not use it . If it was an interface then i could apply a different implementation for when you are running a lib as a GUI . I certainly dont have the time to fix it properly. Yes inheritance can be used well but i have seen so many cases of corporate frameworks using MyCompanyEntityBase to load in all sorts of crap ( we learned this was bad with ORM) . So IMHO like multiple inheritance the cost is not worth the few cases where you benefit. And like Shap i noticed that virtual methods* calls were rarer than i thought , in a lot of code they just use the inheritance to convey additional type information which results in more readable code then using a type field. * Except C# ToString() , GetType() , GEtHashCode() which are mostly bad ideas. Also note C++ people use inheritance a lot more but Java /C# use them less especially in good code due to interfaces. Shap is implementing an interface ICar , class = Honda not "subtyping" the defintions are confusing Here is one from the wikipedia page "Subtyping should not be confused with the notion of (class or object) inheritance <http://en.wikipedia.org/wiki/Inheritance_(computer_science)> from object-oriented languages;[1]<http://en.wikipedia.org/wiki/Subtyping#cite_note-FOOTNOTECookHillCanning1990-1>subtyping is a relation between types (interfaces in object-oriented parlance) whereas inheritance is a relation between implementations stemming from a language feature that allows new objects to be created from existing ones. In a number of object-oriented languages, subtyping is called*interface inheritance*, with inheritance referred to as *implementation inheritance*." Ben On Sat, Jan 11, 2014 at 7:50 AM, Jonathan S. Shapiro <[email protected]>wrote: > As part of the private conversation, Ben and I were pushing to see how far > we can get *without* putting inheritance into the language. We were > hopeful that interfaces would subsume inheritance. Here's where I am on > this at this point. > > I reviewed the use of *ad hoc* subtyping in the Coyotos kernel. There > actually *are* a few places where *ad hoc *subtyping is being used, but > they fall into two cases: > > 1. Heterogeneous lists that are threaded through the objects. This is > mainly for things like ageing lists. Note that while we *don't* have a > closed union in this situation, we *could*. > 2. Cases where a generic object pointer is downcast. So far as I can > determine, every single one of these is accompanied by a type tag. For > example, we know that the object reference in a Page capability names a > Page data structure, and we know it is a Page capability because its type > tag says so. This might not even require dependent type - the defrepr > intuitions are probably good enough. > > I am inclined to think that if we actually have it down to these two > cases, we should maybe push harder to see if we can get the use of > subtyping fully removed. The second case can clearly go. The first case is > harder. > > In most codes, case [1] could be handled, because the objects would be > reference types. When that is the case, we can stick interfaces to those > objects in the actual queue [*] and let the interface implement checked > downcast as part of its signature. > > [*] Though this raises an interesting question about interfaces as objects > that I will bring up separately. > > > What I'm inclined to do at the moment is proceed as follows: > > 1. Reserve syntax for subtyping, both for type definition and type > specification so that we can add it compatibly later > 2. Do not otherwise implement support for subtyping at this time, > focusing instead on dependent types. > > Then I want to see what we have left that we still can't express in the > Coyotos kernel, and see what (if anything) we want to do about that. > > > shap > > _______________________________________________ > bitc-dev mailing list > [email protected] > http://www.coyotos.org/mailman/listinfo/bitc-dev > >
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
