• (nodebb) in reply to Naomi

    I agree with collections, .NET should have implemented equality natively (given that there is object.Equals virtual method which I oppose entirely, but that's a different topic we already covered). There is, however, "SequenceEquals" extension method under System.Linq, which accomplishes the task. Also, what you can do usually is provide your own comparer, for example Dictionary<,> ctor takes comparer for the key, so does HashSet<>, etc. If you need to equality a lot, you can create a few comparer classes which handle most common types you need compared, such as various collections, you do it once, takes a few minutes, and then you just remember to pass those comparers whenever needed.

    Again, I agree that it's silly to define object.Equals virtual method, but not override it in classes which are crying out for it. On the other hand, there just aren't many other types for which equality even makes sense. Yes, collections can be compared, but that's probably one of the very few exceptions; most other equatable types implement Equals correctly.

  • Naomi (unregistered) in reply to 516052

    I think the point I marked ¹ above is also related to why I don't find properties particularly interesting - I just don't write a lot of accessor methods. I honestly consider them a bit of a code smell (although there are exceptions - sometimes you just need a record type for data interchange, or a POJO to deserialize into). I just checked my current big hobby project, and, not counting record types, there's a grand total of one method that can be unequivocally called an accessor, and another that's borderline.

    I can definitely see how they'd be a huge help in a code style that made heavier use of accessors, and how they're more convenient for reflection.

  • Naomi (unregistered) in reply to Mr. TA

    On the other hand, there just aren't many other types for which equality even makes sense.

    How about database proxies? If I've got two objects that both represent the same row in a database, they should be equal, even if they were generated by different queries.

    Or strategies? If I have two instances of a strategy, and they're the same implementation with the same configuration (if applicable), then I'd say they should be equal. That sort of thing comes up a lot during testing, at least for me.

    Again, it isn't a huge deal - it's just inconvenient for the style I'm used to, and that's all I'm saying.

  • (nodebb) in reply to Naomi

    If you are referring to proxies generated by ORMs, it's the ORM responsible for implementing the equality. To my knowledge, the 2 big ORMs - Entity Framework and NHibernate - both do. But I may be wrong.

    The 3 ways to create "in place" types in .NET - 1) Tuple<> class, 2) C# tuples in the form of "(a, b)" backed by ValueTuple<>, and 3) C# anonymous types, all implement Equals and GetHashCode.

    I'm not sure what a "strategy" is?

  • (nodebb) in reply to Naomi

    Regarding properties, here is an incomplete use of widely adopted use cases: 1) POC(J)Os/DTOs; 2) UI control/element configuration; 3) optional injection by IoC containers; 4) calculated getters (such as DateTime.Year); 5) "options" classes (such as JsonSerializerOptions.Indentation); 6) lazy loading, including ORM proxy property overrides for lazy hydration; etc.

  • Naomi (unregistered) in reply to Mr. TA

    Okay, some of those seem like a wash (I don't see any advantage to Year over year()), but some of the others do seem interesting, especially #2 and #5. It actually does make a lot of sense how abstracting the difference between "field" and "setter" would be valuable to a reflection-based framework, and writing an "options" class like you described would mean a lot of boilerplate.

    I'm not sure if it's enough to change my mind on C# as a whole, but I think I get why people like this feature so much, at least.

  • WTFGuy (unregistered)

    @Naomi . I assume you understand that in .Net any type you define can, and is expected to, override the .Equals() method to be a business-meaningful comparison. As well it can, and is expected to, implement the IEquatable and/or IComparable interfaces. None of which involves exposing internal properties or fields to external reading or writing.

    Reference equality is the default for the lowest base-most generic Object type because what else is available to compare for a class with no properties or fields?

    Now in an ideal world they'd have had a way to force all inheritors all the way up the chain to supply and correctly implement those overrides and interfaces. But they didn't and now they can't.

    That doesn't mean you and your co-workers can't be thorough about this.

  • MiserableOldGit (unregistered)

    It's two (maybe three) schools of teaching here, and I can't say which is right because they are, I think, aiming at different objectives.

    1. Get the guys coding in the quickest and easiest way possible, and that's going to be Python, it would have been Basic when I was a kid but that wasn't the path I was on.
    2. Go for something independent of all the commercially relevant stuff just "because", so make them learn Forth or Pascal or some old version of Fortran (like what I got ).
    3. Be relevant but whorish and give them something from .Net, Java or I suppose Python fits in again ...

    But it comes back to the question of whether you can "teach" computer programming, is it an art or a science?

    Decades into this mess, I'm not sure we are any closer to sensible answers .....

  • Naomi (unregistered) in reply to WTFGuy

    Why, exactly, are men on the Internet so quick to lecture me about basic programming concepts? Yes, I know what polymorphism is.

  • Peter of the Norse (unregistered)

    I was looking around for that strange string check, and I found https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/toString#using_tostring_to_detect_object_class which is suppose s a thing, but why wouldn't you use https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/typeof or https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/instanceof ?

    This is actually more common than you think. I’ve seen x.constructor == String, x + '' === x, x.constructor.name == 'String', x.constructor.prototype == ''.constructor.prototype and dozens of variants because it they don't work. Stop trying to reinvent to wheel.

  • (nodebb) in reply to MiserableOldGit

    I'd say, teach low level stuff first, starting with non programming stuff like networks, logical math, etc, then some assembly and C/C++, then highest quality commercial stuff, perhaps both Java and .NET, and choice of business systems orientation, like SQL, or games, or desktop software.

Leave a comment on “Subline Code”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article