• John (unregistered)

    Does it compile or not ?

  • deleted (unregistered)

    I'm still not sure I get what the developer was trying to accomplish. I think he wanted a kind of attribute (since it is an encapsulated class) which is used several times, and some of those times the value can be updated, and other times, not (hence, the derived class which is updateable).

    IF that is the case, then it should have been done as such: class RecordBase { public class DateTimeAbstract { public foo { get; } public bool set()... }

    public class DateTimeStatic : DateTimeAbstract
{
    public bool set() { return false; }
}

public class DateTimeDynamic : DateTimeAbstract
{
    public bool set() {...}
}

    };

    Yes, I know my syntax is off - but hopefully you get the point.

  • Slapout (unregistered) in reply to The Fury
    The Fury:

    How about dew?

    http://www.telegraph.co.uk/culture/tvandradio/8395270/Ten-of-the-most-ridiculous-excuses-for-late-trains.html

    So, that's an article on the Website of a Newspaper that has the name of a Morse code sending machine and it's in the paper's Tv and radio section.

  • n9ds (unregistered) in reply to Slapout
    Slapout:
    The Fury:

    How about dew?

    http://www.telegraph.co.uk/culture/tvandradio/8395270/Ten-of-the-most-ridiculous-excuses-for-late-trains.html

    So, that's an article on the Website of a Newspaper that has the name of a Morse code sending machine and it's in the paper's Tv and radio section.

    Of course! How else do you send Morse code except by TV or radio?

  • (cs) in reply to Maj najm
    Maj najm:
    faoileag:
    Hasse de great:
    Yellow Snow?
    "Don't eat yellow snow!"

    Eat yellow snow, it might be beer!

    Of course, it might be used beer as well.

    More often than not, "yellow snow" is no longer "snow" but solid re-frozen slush. Sometimes hard as a brick. It depends on the temperature!

  • (cs) in reply to Remy Porter
    Remy Porter:
    The "right" answer is to avoid situations where you implement code to this pattern. But there are two better answers to this. The first is to simply have the base class throw a NotImplementedException in the set

    WRONG.... It should be a NotSupportedException(). NotImplemented is designed specifically to be used by development so there are valid semantic placeholders for functionality that has not yet been implemented.

    Proper pre-release testing should include a solid scan to ensure that there are NO instances of NotImplemented!

  • (cs) in reply to n9ds
    n9ds:
    How else do you send Morse code except by TV or radio?

    Dedicated landline.

  • OPPenguin (unregistered)

    Correct me if I'm wrong, but that appears to be Java. And if that is Java, then you can't reliably use '==' on strings. It needs the equals() method.

    So it's even more wrong.

  • Tux "Tuxedo" Penguin (unregistered) in reply to Doctor_of_Ineptitude
    Doctor_of_Ineptitude:
    This is not an error. This is a sadistic plot to inflect pain and suffering (in this case, specifically to Alex). So, Alex, what did you do to antagonize Satan or his minions?

    He's AFAIK devoted church-goer.

  • (cs) in reply to herby
    herby:
    Maj najm:
    faoileag:
    Hasse de great:
    Yellow Snow?
    "Don't eat yellow snow!"

    Eat yellow snow, it might be beer!

    Of course, it might be used beer as well.

    More often than not, "yellow snow" is no longer "snow" but solid re-frozen slush. Sometimes hard as a brick. It depends on the temperature!

    It makes a patch of yellow snow an excellent weapon for poking out the eyes of husky-thieves. The act of urination (particularly canine, being close to the ground makes the stream more collimated) forms a sort of solid yellow ice-cone with a more-or-less sharp tip.

  • (cs)

    Did anyone else think of BuildMaster when they saw "Alex" blaming "invisible" people for the dodgy code?

  • TheCore (unregistered)

    If this is C# its soooo easy....

    public bool MyProperty { get; private set; }
  • (cs) in reply to TheCore
    TheCore:
    If this is C# its soooo easy.... 
    public bool MyProperty { get; private set; }

    Sorry, but private set is causing much problems if not used correctly.

  • (cs) in reply to faoileag
    faoileag:
    Remy wrote:
    a mysterious, uninformative, and untyped exception
    What's uninformative about "Cannot call set on RecordDateTime for table <insert_table_name>"?

    Everything. It tells you that something broke, but not why, or what you can do to fix it. The message is a completely redundant. The mere fact that this would cause an exception indicates that you can't perform that operation, so the message is not telling you anything that you don't already know.

  • (cs) in reply to OPPenguin
    OPPenguin:
    Correct me if I'm wrong, but that appears to be Java.
    That isn't Java.
  • sol (unregistered)

    hmm... does this code fall into that category

    public void SetAnyPrivateFieldYouKnowTheNameOf(object target, string fieldName, object value) { var t = target.GetType(); var f = t.GetField(fieldName, BindingFlags.NonPublic | BindingFlags.Instance);

            if (null != f)
            f.SetValue(target, value);
    }
  • (cs) in reply to TheCore
    TheCore:
    public bool MyProperty { get; private set; }

    Because in C# classes are sealed (aka final in java) by default, subclasses wouldn't be able to override the setter. My solution would be:

    public class Base
{
	public string Prop { get; protected set; }

	public Base() { Prop = "initial"; }
}

public class Sub : Base
{
	public new string Prop { get { return base.Prop;  } set { base.Prop = value; } }
}

public class Program
{
	static void Main(string[] args)
	{
		Base b = new Base();
		//b.Prop = "set"; Can't write, because Prop is read-only
		Console.WriteLine(b.Prop);

		Sub s = new Sub();
		Console.WriteLine(s.Prop);
		// Writeable because Sub.Prop shadows Base.Prop
		// (an entirely new property that just happens to call its base to store the data)
		s.Prop = "set";
		Console.WriteLine(s.Prop);

		Base sb = new Sub();
		//sb.Prop = "set"; Can't write because Prop is read-only in declared class
		Console.WriteLine(sb.Prop);
	}
}

    This still allows the classes themselves to set Prop, because it has a protected setter, but doesn't allow the consumer of the API to set Prop when the subclass doesn't shadow Prop and implements set (a property with a different name would work the same, of course). It depends on whether or not you're designing an API.

  • Nagesh (unregistered)

    Thank you for providing codes. Very much appreciate!

  • Neil (unregistered) in reply to OPPenguin
    OPPenguin:
    Correct me if I'm wrong, but that appears to be Java. And if that is Java, then you can't reliably use '==' on strings. It needs the equals() method.
    Unless those strings were interned, which seems likely for literals and class names.

Leave a comment on “Making Off With Your Inheritance”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article