Re: Damn sisters :-)
Re: Damn sisters :-)
- Subject: Re: Damn sisters :-)
- From: Brian Luft <email@hidden>
- Date: Tue, 11 Dec 2001 06:19:18 -0600
On 12/11/01 2:09 AM, "Thomas Lachand-Robert" <email@hidden> wrote:
>
>
Le lundi 10 dicembre 2001, ` 10:52 , Brian Luft a icrit :
>
>
> This is totally unrelated to the topic at hand, but one of the really cool
>
> things about C# (no Microsoft flames, please :P) that I wish Objective-C
>
> had
>
> are properties. They let you simulate normal member variables but
>
> actually
>
> call accessor and set functions.
>
> For instance, you can have a String myStr property that actually sets
>
> something in a dictionary in its implementation, like in Ondra's example,
>
> transparently. This lets the user do simply:
>
> MyClass.myStr = "Blah"
>
> String myLocalStr = MyClass.myStr;
>
> And both will not set the variable directly but will instead call the
>
> associated get or set function. Pretty neato, if you ask me ;)
>
>
>
> Thanks. Brian
>
>
>
I strongly disagree. There is, in my opinion, a large number of
>
inconvenients in doing this:
>
- it leads developpers to confuse real members to fake ones, and to
>
believe that it is harmless to expose the members: IT IS NOT; (BTW you can
>
achieve a similar effect in C++ with MyClass.myStr(); at least here you
>
don't forget you call a funtion.)
I see where you're going with this, I think. I'm not sure I see what the
harm in doing this is, though.
>
- it leads developpers to forget that typing MyClass.myStr really calls a
>
(possibly expensive) function, hence causing waste and time and space.
Good point, very true.
>
- it incitates to use extremely short names difficult to understand;
>
[myObject getDescriptiveString] is cleaner than myObject.myStr. The more
>
you type, the better your program.
You could just as easily name your variable myObject.descriptiveString.
Then, I don't see how [myObject getDescriptiveString] is cleaner than
myObject.descriptiveString.
Thanks. Brian