I am looking at the String class in Actionscript 3.0.

It has a property called String.length . Internally it's a getter function (or method ?) that returns the length of string.

Why can't it be String.getLength() ?

Methods can take in 1, 2 or more values...so their significance can be understood. But what significance does "property" have? As it is, after all, a function only. So, why the categorization into properties? Is it just for adding an overhead botheration to remember that something has been categorized into a property?

In other words, as a programmer, how am I helped when I'am told that String.length is a property of the String class when I can't find any method for the same.

While writing a program, how would I know what is a property and what is a method?

I appreciate having someone shed some light on this.


  • Gahgrani, are you asking about difference of property and method?
    – Yusubov
    Aug 2, 2012 at 8:17
  • well, it would help me if i take a specific case. Say, why String.length ? Why not String.getLength() ? How the programmers decided to put it as property.
    – Vishwas
    Aug 2, 2012 at 8:19
  • 4
    See Properties vs Methods Aug 2, 2012 at 8:21
  • 2
    Properties represent state, methods represent behaviour.
    – MattDavey
    Aug 2, 2012 at 9:39
  • In my opinion @MattDavey's answer is the definitive one. +1, indeed.
    – NoChance
    Aug 2, 2012 at 9:55

3 Answers 3


String.Length is a read/only property, so it's possibly not the best place to start.

Imagine you have a Person class that needs to store a persons full name.

In Java, you might create a pair of methods, setName() and getName(), to handle this value. That's two methods, required to handle a single value.

It's only convention that links those two methods together. Someone who didn't know the convention - say, someone self taught - might instead write AssignName() and Name() methods. It is, after all, just a convention.

By formalising the relationship into something called a property, C# (and other languages) remove the need for developers to know about, and to adhere to, the same convention as everyone else.

Once you have the unified property, there are other benefits. For example, you can pass a property as an out or ref parameter if you want, you can't do that with a pair of methods.

As you look across other programming languages, there are other examples of this approach to be found.

  • An Interface is "just" a pure abstract class.
  • A Delegate is "just" a function as a value.
  • MethodMissing() and dynamic are "just" ways for a class to allow you to call methods that don't exist.
  • An event is "just" the way the language supports the Observer pattern.
  • The async and await keywords in C# 5.0 are "just" another way to write asynchronous code.
  • Extension Methods are "just" static methods.

Except that all of these things are more than what they are "just". They increase the expressiveness of the language involved, allowing better abstractions and more effective code.

  • Bravo! One of the best answers I've read on programmers. I certainly don't miss writing get and set methods for everything!
    – Tjaart
    Aug 2, 2012 at 11:40
  • Personally I would rather have Name as a readonly property, and Rename() as a method. From that perspective I would say that AssignName() and Name() are closer to correct then get/setName.
    – MattDavey
    Aug 2, 2012 at 11:50
  • 1
    @MattDavey - For domain objects that mirror the real world, I agree to a large extent, though I'm not sure this is relevant to the OP. Last year I gave a presentation where this was one of the key techniques advocated: nichesoftware.co.nz/page/486/lesser-known-design-patterns
    – Bevan
    Aug 3, 2012 at 1:38
  • Having syntactic sugar for unified properties can be nice, but there are things one can do with methods which cannot be done with unified properties; outside of the syntactic sugar (which compilers could have allowed for methods tagged with suitable attributes) is there anything properties can do which methods cannot? If it were possible to pass a "property of T" type containing a getter and setter, that would be useful, but I don't know of any such feature. And passing properties as ref parameters is problematic at best.
    – supercat
    Aug 8, 2012 at 22:27
  • @supercat - One can just as easily say "is there anything objects can do which structured programming cannot". From a technical perspective, everything can be achieved by writing processor instructions directly - indeed, this is all that compilers do for us. The advantage is not in capability, the advantage is in abstraction and it's stablemate, encapsulation - the syntactic sugar hides details away so that we don't need to reason about quite so much as we work.
    – Bevan
    Aug 9, 2012 at 1:17

Short Answer: String.Length is a getter property of the string object. It is a read-only property without a set modifier in the .NET Framework.

As suggested, have a look at this comparison - SO discussion on Properties vs Methods

Also read from the official documentation of String.Length


The difference comes from the fact the some languages have different naming contexts for different stuff. I will speak in examples and not so precise definitions as to be more clear.

Example 1: JavaScript - single naming context

  • functions are callable which when called execute code, might have side effects and return value
  • objects are, well... anything but null and undefined, even functions, primitives etc.
  • all these have names, so when you use a name to connect an object or function to another object they all become properties of the new object and that's it.


var object = {};
// they all share the same naming context of object
object.fn = function() {}; // adding a function property which becomes a method
object.number = 1; // adding a primitive type property
object.object = {}; // adding an object property
// object.fn = 2; // will overwrite the method

Example 2: Java - double naming context

  • functions are callable, execute code, side effects, might return value
  • functions can't exist if they are not attached to an object by having some name thus becoming methods (method is a function which has this)
  • all functions share same naming context on an object, and can even have more than one with the same name only if they have different parameters
  • anything other than function, which is an object or primitive, can also be connected to an object by a name and they share different naming context from methods


class JavaObject {
    public void property(){}; // function attached to an object is called method
    public void property(int){}; // multiple functions with same name allowed
    public int property;  // the same name, but in a different context, still ok
    //public long property; // this one's name wiil clash with the int property

Long story short: Some languages can have methods and non-methods as properties with the same name, thus we try to point out which of them we talk about.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.