Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I am looking at the String class in Actionscript 3.0.

It's having a property String.length . Internally it's a getter function ( or method ?) returning the length of string.

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

Methods can take in 1, 2 or more values.. so their significance can be understood. But what significance "property" has. As it's afterall, a function only. So, why categorization into properties? Just adding an overhead botheration to remember that something has been categorized into property ?

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

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

Appreciate having some light on this.

V.

share|improve this question
    
Gahgrani, are you asking about difference of property and method? –  Yusubov Aug 2 '12 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 G Aug 2 '12 at 8:19
4  
See Properties vs Methods –  Martijn Pieters Aug 2 '12 at 8:21
2  
Properties represent state, methods represent behaviour. –  MattDavey Aug 2 '12 at 9:39
    
In my opinion @MattDavey's answer is the definitive one. +1, indeed. –  Emmad Kareem Aug 2 '12 at 9:55

3 Answers 3

up vote 10 down vote accepted

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.

share|improve this answer
    
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 '12 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 '12 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 '12 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 '12 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 '12 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

share|improve this answer

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.

So:

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

Thus:

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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