• Prime Mover (unregistered)

    I confess I did this in java (at least) once when that was what I programmed in for a living

    public getSomeProperty get () {
    return this.getSomeProperty();
}

    In my defence, a) I perpetrated this before I'd had my first cup of java in the morning, and b) I at least ran it to observe the stack dump ...

  • Prime Mover (unregistered)

    Sorry, should read:

    public someProperty getSomeProperty() {
    return this.getSomeProperty();
}

    ... need some java

  • my name (unregistered)

    I once was in a project where some tasks were outsourced. The project leader used some website where freelancers could be contracted (pun intended). As we got this part of the project back it was my turn to install it and interface with it. At the beginning there were some small errors in the installation where the developer reacted quite quickly. After testing it for months we discovered a logic bug that rendered this useless for us, from then on we were ghosted. I left a few weeks later, I learned afterwards that the whole project was rebooted and handed to another company. So much for outsourcing

  • (nodebb)

    The real WTF isn't the code: it's the process that let people hand this code off as if it were a completed set of requirements.

    Worse: From the description, it did meet the requirements, which isn't hard, if they don't say anything.

  • RussellF (unregistered)

    It's not entirely correct to call properties mere syntactic sugar, they can do that getter and setter methods can't; for instance, they make serialization much simpler.

  • (nodebb)

    ´´it's [property] syntactic sugar

    That is actually not correct; by this definition everything would be syntactic sugar :) Properties are framework objects supported down to the framework view reflection and are first class targets for inlining (hence you should never pack complex logic into properties and keep them compact and without any side-effects). If they would be just syntactic sugar like Java generics (type erasure), you couldn't do stuff like ´´typeof(MyClass).GetProperties().FirstOrDefault()?.GetSetMethod()?.Invoke("Properties are not syntactic sugar");´´ while also have the same property inlined in case the class/struct allows for it (like being sealed, you should always seal all classes but those intentionally left open, but those are very rare exception, cause composition over inheritance).

    So yeah, the correct statement would be "properties are first class language constructs directly supported by the framework, engine and both the compilers and JIT compilers down to the runtime" :-)

    BTW ´´init´´ is actually syntactical sugar, similar to ´´require´´ when we are talking properties.

    Going back to the Bug, property names must always be PascalCase (while private fields are not clearly defined because there were different naming convention revisions). So that was the actual mistake, because while I also personally prefer "_field" over the old "m_field", the short lived "field" in combination with this was an official recommendation a few years back for a short time but really nobody likes this (the keyword).

  • Sole Purpose Of Visit (unregistered)

    It's not actually "casting" the property to an object: it's defining the type of the property. I suppose you could describe any typedef in any language as a cast from "hasn't had a type assigned yet" to "here's the type," but I don't think this is a useful elision.

  • (nodebb)

    I suppose you could describe any typedef in any language as a cast from "hasn't had a type assigned yet" to "here's the type,"

    That is entirely unrelated to how I'd describe a C/C++ typedef, which merely defines an alias for an existing type.

  • (author) in reply to MaxiTB

    I call it syntactic sugar because this code: myObj.x = 5 and this code myObj.y = 5 are wildly different things- x is a property which raises an exception if the value is out of range, and y is just an exposed field.

  • Richard Brantley (unregistered)

    I guess their contract also didn’t require unit tests.

  • LZ79LRU (unregistered) in reply to Richard Brantley

    Unit tests? Given the issue at hand it apparently didn't even require running the project once to confirm it would.

  • Erin (unregistered)

    If they received something that compiles, it's already ahead of most of my experiences with cheapest-you-can-find contractors.

  • (nodebb) in reply to MaxiTB

    If they would be just syntactic sugar like Java generics (type erasure)

    Generics in Java are System-F Sub. They're as fundamental to the semantics of the language as "int" or "Object" or "if". Saying they're just syntactic sugar is tantamount to saying that all types are just syntactic sugar.

    Generics get erased at runtime because the compiler can prove the constraint on types is never violated. So do ints for that matter. The code won't compile unless and until the compiler can make the proof that the types are satisfied.

    If you need proof that all types are not just syntactic sugar, look at dynamic languages. Types aren't erased at runtime exactly because they have to be checked to guarantee program soundness.

  • (nodebb) in reply to Remy Porter

    I don't understand your example. What are those? Fields? Properties? Even if x (wrong naming convention for both BTW) is a auto-property, why would it raise an exception? That's not how it works. And abusing properties for validation is a clear anti-pattern because properties should not raise exceptions in the first place. Plus you should never ever expose fields in a public/internal/protected context - that's an anti-pattern since 2.0 (technically since the beta, but eh back in the pre 2.0 days inlining was not 100% perfect) :-)

  • Airdrik (unregistered) in reply to MaxiTB

    He's pointing out that a property access and a field access look the same to the untrained eye who isn't familiar with the conventions used to distinguish them. "syntax sugar" is a piece of syntax which covers and simplifies some more complex underlying behavior, which is exactly what the syntax for property access is doing: it's turning a method call into what looks like a field access while hiding/obscuring the fact that you're invoking something which may involve more complicated behavior you didn't expect like accessing a database and throwing exceptions. Sure there are conventions around how to name things to make it obvious that it isn't simple field access, but it's still syntax sugar.

  • akozakie (unregistered)
    Comment held for moderation.
  • (nodebb) in reply to WatersOfOblivion

    That's my point. If there are any constructs which doesn't exist on runtime level (and I totally count Java generics as such, because you can't even construct them from a generic template dynamically, because there is no generic template type obviously compared to a proper implementation like in .net - Java generics are basically poor-mans C++ templates) than it is not appropriate to call any runtime construct syntactic sugar especially if doesn't have any alternatives to it.

    Another wrong example is calling using a replacement for try catch - this is far from true because using get in some cases special treatments in async context, you cannot replicate with other language constructs.

    So it makes sense to consider everything syntactic sugar that has no representation on the runtime level when there is an intermediate language layer (IL in .net, bytecode in Java) or for languages with output direct machine code basically language constructs with the same output on the machine code layer (like in C *x and x[0]).

  • (nodebb) in reply to Airdrik

    Ah okay, but that is not true.

    public int X { get; } looks nothing like private int _x;

    Keep in mind, in .net naming conventions and best practices are there for an reason:

    (1) Always use (auto) properties except for private members. (2) Property names are PascalCase. (3) Private field members are camelCase with a prefix "m_"/"s_" (old notation) or "_" (most common used these days).

    So as you can see, there is no way to mix them up without violating the naming conventions or best practices. Plus as I mentioned before, properties are first class targets for inlining on the IL and JIT level, so there is no overhead as long as you don't make the property virtual AND don't seal the class.

  • Lurk (unregistered) in reply to MaxiTB

    "...Keep in mind, in .net naming conventions and best practices are there for an reason:"

    If you're relying on naming conventions to save your backside, then $DEITY preserve you.

  • Stuart (unregistered)

    In fairness, I've written code that is just as bad.

    Against that, I actually TEST my code to verify that it has at least vague pretensions of doing what it's supposed to do. It may not be robust. It may not be reliable. But there will be at least one circumstance where it actually does what it's supposed to do.

    Which reminds me of the time I caught up with a guy I'd worked with previously. He introduced me to some of his staff: "Stuart wrote some of the interfaces for {system} - the ones that worked." Which, well, okay, I'll take the compliment, but it's not exactly a glowing endorsement of that codebase. (Though I don't have much to say about the codebase that's positive, to be honest. I'd submit something to the Daily WTF about it, but the code is something I've not had access to for over twenty years now.)

  • Sole Purpose Of Visit (unregistered) in reply to Steve_The_Cynic

    It is, but I don't really care.

    Use the appropriate synonym of choice. This is not a cast in VB.Net. It is the assignation of a type. Which is because VB inherits a different model of type definitions from that used in C/C++. To whit:

    // C++
integer foo;

    ... and ...

    // Certain older languages, quite often functional or modeled thereon
foo : integer

    In neither case is a cast involved, and it's fairly easy to see why. A cast generally happens at runtime in a polymorphic language. The assignment of a type happens during the compiler/interpreter stage, and will not throw an exception at runtime. This is a type assignment. Not a cast.

  • Sole Purpose Of Visit (unregistered) in reply to MaxiTB

    I agree that "properties should not raise an exception." In an ideal world. We do not live in an ideal world.

    AFAIK, there is not a single language that restricts properties in this way. (I'd be in favour of one that did.) My code-base, and I imagine several others, have a time-bomb tech-debt built in via side effects that should not be there. Consider this in C#.NET:

    int _whoopsie;
int complicatorsGlove
{
    set
    {
        _whoopsie = value;
       GlobalWidget.UpdateState(_whoopsie);
    }
}

    Particularly if GlobalWIdget is a WInForm/WPF Control, this is practically certain to come back and bite you. Either with a stack overflow, or with an exception. And there's no way for the compiler, or the programmer, to tell.

  • LZ79LRU (unregistered) in reply to MaxiTB

    Naming conventions are just that, conventions. As in non binding agreements not enforced by the compiler. Therefore they are not to be relied upon for anything.

    After all, if there is no strict enforcement than the only reason to follow them is professional ethics and a desire to write good code. And those are precisely the sort of traits that lead to not producing code containing precisely the sort of problems that the conventions are meant to solve in the first place.

    Conventions make good code better but they can't and won't make bad code safe.

  • Apeiron (unregistered) in reply to MaxiTB
    Comment held for moderation.
  • Craig (unregistered)
    Comment held for moderation.

Leave a comment on “The Properties of Contract Development”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article