Posts

Showing posts from November, 2007

Too many people

Overcrowding is a common fear these days, just like global warming and other similar crap. I just thought I'd save here a quick calculation to put things in perspective. Living area for a single person: 100 m^2 (this would make it 400 m^2 for a 4-people family) Number of people you can fit in a km^2: 10,000 (because 1 km^2 = 1 million m^2) Land area of the Earth: 148 million km^2 (see Wikipedia ) Say only a fifth of that area is available for people, that would be 30 million km^2. Multiplied by 10,000 this gives us 300 billion people. 300 billion people. With no many-stories buildings, no overcrowding a la Asimov's fiction (how on Earth could he estimate only 40 billion people for Trantor I cannot imagine) and no food problems ('cause we have four fifths of the land area for that - in fact, even if we remove 30% of the total area as desert it still leaves us with 70 million km^2 for animals and crops). One other thing - what the overcrowding gang never mention is this: on

Non-nullable reference types in C#

C# 1.0 has non-nullable value types (an int variable must always have a valid int value, it cannot be null) and nullable reference types (a string variable can be null). C# 2.0 added nullable value types (an int? variable - note the "?" - can be null). There are unfortunately no non-nullable reference types (a string variable which can never be null). Patrick Smacchia has a summary of a possible notation and also of the issues that could appear. However, until Microsoft decides to add non-nullable reference types, there's a way of doing the same thing with a somewhat more complicated notation. using  System;      namespace  Extensions   {      public   struct  NotNull<T> where T :  class      {        public   readonly  T value;           public  NotNull(T arg)       {          if  (arg ==  null )            throw   new  ArgumentNullException( "arg" );            value = arg;       }           // convert non-nullable to regular         public   static   i

Structure of Object-Oriented systems

Image
Objects are state machines Real-life entities have state. Your checking account has an amount of money; your car has a mileage, a gas level, a speed and so on. Objects in an application should also have a state and a set of operations that can manipulate that state. (You can change the color of your car or add money to your checking account; you cannot do the opposite.) That being said, we normally want to hide the state and expose operations because it reduces coupling, which in turn reduces the "brittleness" of the whole system. Tell, don't ask Objects shouldn't have getters and setters; this is sometimes called the "tell, don't ask" principle . There are two cases where getters appear to be necessary: Asking an object for some information and then deciding what how to change the state of the same object. This code could be a fragment of a ping-pong game: if  (ball.Y < 0 || ball.Y > MAX_Y)     ball.SpeedY = ball.SpeedY * -1;   A much better way t