Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > C# properties using C++ Templates, is it Possible?

Reply
Thread Tools

C# properties using C++ Templates, is it Possible?

 
 
Ben Pope
Guest
Posts: n/a
 
      11-23-2005
Brent Ritchie wrote:
> "Ben Pope" <(E-Mail Removed)> wrote in message
>>
>> And if you consistantly use the function notation, then you are
>> simplifying the interface.
>>

>
> Simplifying yes, Easier to use, maybe. When creating a class, you
> have to watch the length of your member names that you use. If you
> don't then you run the risk of losing time writing and rewriting long
> member names especially on members that add functionality for private
> variables as they are usually used most. I think that if it makes
> sense then symbols are better.


OK, I'm not with you:

class Thing {
private:
int minutes_;
int hours_;
public:
int& minutes();
int& hours();
};

Member names for accessors are the same (except the underscore) as the
private member variable.

>> Additionally, providing direct access to the members (or appearing
>> to) doesn't really hide the implementation details.
>>

>
> In a way, it does. Take the Clock example again. If I go
> clock.Seconds++ and clock.Seconds is already equal to 59 then
> clock.Seconds++ would set itself to 0 and do clock.Minutes++ at the
> same time to simulate a real clock. Someone using this class knows
> that this happens they just don't have to know how it actually
> happens. They are just glad that it does happen with no effort on
> their part.
>
>> Having said that:
>>
>>
>> class Thing { int property_; public: const int& property() const {
>> return property_; } int& property() { return property_; } };
>>
>> int main() { Thing thing; thing.property() = 4; int myProperty =
>> thing.property(); }
>>
>>
>> Whats wrong with those two ways of exposing the properties? It's a
>> pretty simple interface. You don't have to prepend the functions
>> with get & set, just take advantage of overloading.
>>

>
> Nothing is wrong with any of those, they are valid and easy to read.
> But the problem is when you add funtionality what happens whan you
> want to add one to your property? you would have to right a function
> say addProperty(int val) { property += val; } where as
> Thing.Property++ or Thing.Property += 1. is shorter and is still
> obvious to the user.


No you don't; from my trimmed example above:

thing.property() += 4;

Perfectly valid code.

> Also the way you do it, I have to rewrite the default functionality
> for each member every time I write a class. With my template I can
> have the basic functionality as soon as I declare it, and extend it
> as I see fit.


That's pretty lazy. There shouldn't be that many times you want to
provide direct access to the members, and when you do, you'll want to
minimise access as much as possible, which will require writing a small
amount of code.

Ben Pope
 
Reply With Quote
 
 
 
 
Brent Ritchie
Guest
Posts: n/a
 
      11-23-2005

"Ben Pope" <(E-Mail Removed)> wrote in message
news:1132754339.7c1ad6ee0da67ad1ffae098b5f82ec18@f e5.teranews.com...
> Brent Ritchie wrote:
>> "Ben Pope" <(E-Mail Removed)> wrote in message
>>>
>>> And if you consistantly use the function notation, then you are
>>> simplifying the interface.
>>>

>>
>> Simplifying yes, Easier to use, maybe. When creating a class, you
>> have to watch the length of your member names that you use. If you
>> don't then you run the risk of losing time writing and rewriting long
>> member names especially on members that add functionality for private
>> variables as they are usually used most. I think that if it makes
>> sense then symbols are better.

>
> OK, I'm not with you:
>
> class Thing {
> private:
> int minutes_;
> int hours_;
> public:
> int& minutes();
> int& hours();
> };
>
> Member names for accessors are the same (except the underscore) as the
> private member variable.
>


Yes, thats true but it's not what develoopers are used to. This is not
intuitive to a developer who does not understand your programming style and
does not have the time to give your documentation more then a passing glance
to get the gist of it. When they import your package they can't read your
source to see exactly what you have done because it has been compiled.

My strongest argument for properties is that they are indeed intuitive
and respond like normal member variables to common operations. The only
difference is they have hard constraints that can be changed however you
like. With your implementation you have to derive a new class and override
every mechanism that need tighter constraints. Granted you can use function
pointers but this forces that type of management on to any programmer that
decides to use this type of mechanism. Using a template everything is done
for you and you don't need to woory about the error prone management of
function pointers.

The way you access the features of a class is every bit as important as
the features themselves. More often then not you will never be the only
programmer using these classes, and just as often these classes will span
multiple projects. Now, I don't know if your a professional developer, but I
thought I should remind everyone that this is true in businesses of any
size. I have never worked in industry myself but I do know people in it and
I have learned much from them. People always complain if something makes
their job harder especially when they need the functionality of a specific
package.

>>> Additionally, providing direct access to the members (or appearing
>>> to) doesn't really hide the implementation details.
>>>

>>
>> In a way, it does. Take the Clock example again. If I go
>> clock.Seconds++ and clock.Seconds is already equal to 59 then
>> clock.Seconds++ would set itself to 0 and do clock.Minutes++ at the
>> same time to simulate a real clock. Someone using this class knows
>> that this happens they just don't have to know how it actually
>> happens. They are just glad that it does happen with no effort on
>> their part.
>>
>>> Having said that:
>>>
>>>
>>> class Thing { int property_; public: const int& property() const {
>>> return property_; } int& property() { return property_; } };
>>>
>>> int main() { Thing thing; thing.property() = 4; int myProperty =
>>> thing.property(); }
>>>
>>>
>>> Whats wrong with those two ways of exposing the properties? It's a
>>> pretty simple interface. You don't have to prepend the functions
>>> with get & set, just take advantage of overloading.
>>>

>>
>> Nothing is wrong with any of those, they are valid and easy to read.
>> But the problem is when you add funtionality what happens whan you
>> want to add one to your property? you would have to right a function
>> say addProperty(int val) { property += val; } where as
>> Thing.Property++ or Thing.Property += 1. is shorter and is still
>> obvious to the user.

>
> No you don't; from my trimmed example above:
>
> thing.property() += 4;
>
> Perfectly valid code.
>
>> Also the way you do it, I have to rewrite the default functionality
>> for each member every time I write a class. With my template I can
>> have the basic functionality as soon as I declare it, and extend it
>> as I see fit.

>
> That's pretty lazy. There shouldn't be that many times you want to
> provide direct access to the members, and when you do, you'll want to
> minimise access as much as possible, which will require writing a small
> amount of code.
>


You can call it lazy, I call it economical. If you have a class that is
meant as a datastore and has an internal state of say 20 variables, 8 need
direct access and say 5 need some type of restricted access. This is at a
minimum 21 new members to implement this wil not take a non-trivial amount
of time. It would probably take a nice chunk of an hour. Then they all have
to be tested, which will take more time. Using some type of already tested
mechanism such as properties would greatly reduce this time and is much less
error prone.

Granted it's probably not often you need a datastore but over time every
minute you spend coding is about 10 seconds of testing. The less coding you
do the fewer tests you run, the more real work you can do. Code reuse,
(Where it makes sense) is always a best practice, this means shorter
development times and higher quality software.

This stuff is probably not new but it is fundamental to why I think
properties are better then roll-your-own Accessor/Mutator functions. Already
tested, extendable, common default implementations and intuitive use.

> Ben Pope



 
Reply With Quote
 
 
 
 
Michael O'Keeffe
Guest
Posts: n/a
 
      12-05-2005
That's a great paper - some rational thought on the whole idea behind
"properties"

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Not able to copy all properties using properties.putAll() method. Sonal Java 3 12-07-2007 03:08 AM
CompositeControls: ViewState properties w/ Mapped properties probl =?Utf-8?B?Q2hyaXN0b3BoZSBQZWlsbGV0?= ASP .Net 1 01-19-2006 09:19 AM
Making Custom Control Properties Visible in Visual Studio's Properties Palette Nathan Sokalski ASP .Net 0 10-17-2005 02:05 AM
Re: C++ properties Library Created (was Binding together Properties of Objects) Victor Porton C++ 1 08-29-2004 08:02 PM
Problems parsing when Properties.dtd.properties Kent Lichty Java 0 04-16-2004 03:08 PM



Advertisments