1

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.

V.

Aaron
  • 3
  • 3
Vishwas
  • 1,871
  • 4
  • 15
  • 15

3 Answers3

12

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.

Bevan
  • 3,170
  • 20
  • 22
  • 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 02 '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 02 '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: http://www.nichesoftware.co.nz/page/486/lesser-known-design-patterns – Bevan Aug 03 '12 at 01: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 08 '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 09 '12 at 01:17
  • @supercat - Without negating my above comment, I do have an example - if only a poor one - improved versioning: If you were so rash as to expose a public field, you can replace that with a property and only require recompilation of client code, not a rewrite. – Bevan Aug 09 '12 at 01:19
  • @Bevan: There are things properties can do which public fields cannot; my question was about properties versus *methods*. There are some things methods can do which properties cannot. For example, a parameter-less method returning `int` can be passed to a routine which expects a `Func`, but a property whose `get` method returns `int` cannot be so passed. Aside from the syntactic sugar benefits (which compiler writers could make available to methods if they wanted to), what abilities would property `Foo` have that pair of methods `get_Foo()` and `set_Foo()` would not? – supercat Aug 09 '12 at 20:18
  • @supercat - Given that the implementation of C# properties is based on `get_Foo()` and `set_Foo()` style methods, the entire benefit of the feature stems from the syntactic sugar that you so readily dismiss. Is there anything property `Foo` can do that's unique? Of course not, but that's not the point. – Bevan Aug 10 '12 at 02:02
  • @Bevan: My question is whether there is any benefit from having the *framework* recognize the concept of properties, rather than merely having languages accept property-ish syntax for methods which have a "property" attribute. If a property was nothing more than a combination of a `get` method and a `set` method, for example, it would be easy to have an abstract `ReadableFoo` with an abstract `get` method, and a concrete `MutableFoo` which overrides the `get` and add a `set`. As it is, though, a read-write property cannot override a read-only one. Do such restrictions offer some benefit? – supercat Aug 10 '12 at 14:48
2

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

Community
  • 1
Yusubov
  • 21,328
  • 6
  • 45
  • 71
1

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.

Azder
  • 193
  • 1
  • 8