is anyone else here using D in a C stlye way, ie billions of globals, almost no classes etc?

D just appeals to me because of its much cleaner syntax and no header files, not because of its great OOP capabilities. I especially dont like member protection because im a bedroom coder so i work on my own, so protecting member variables doesnt really appeal to me.

In article <c8ac4b$2kt4$1@digitaldaemon.com>, imr1984 says...
>
>is anyone else here using D in a C stlye way, ie billions of globals, almost no classes etc?
>
>D just appeals to me because of its much cleaner syntax and no header files, not because of its great OOP capabilities. I especially dont like member protection because im a bedroom coder so i work on my own, so protecting member variables doesnt really appeal to me.
>
>

>is anyone else here using D in a C stlye way, ie billions of globals, almost no classes etc?

Probably, Ive seen functional style D , and while I like OO, sometimes it fits better to have free functions .  In fact Id much prefer if the Phobos was all a set of free functions , with an optional OO wrappers to all of it.  Right now its all mixed in all flibbily bibbily stlye , no consistency to speak of.

>I especially dont like member protection
>because im a bedroom coder so i work on my own, so protecting member variables
>doesnt really appeal to me.

I never liked this either, if the getters and setters do nothing more then just that ( i.e. they might check a value for a condition etc ) , then why not just make the data public ?  Even this month I read an article in favor of getters and setters in CUJ, I like python style much better.

Charlie

"imr1984" <imr1984_member@pathlink.com> wrote in message news:c8ac4b$2kt4$1@digitaldaemon.com...
> is anyone else here using D in a C stlye way, ie billions of globals,
almost no
> classes etc?

Empire is written that way.

"Charlie" <Charlie_member@pathlink.com> wrote in message news:c8aq9o$94k$1@digitaldaemon.com...
> I never liked this either, if the getters and setters do nothing more then
just
> that ( i.e. they might check a value for a condition etc ) , then why not
just
> make the data public ?

I agree. The common get/set for a simple member variable just looks like clutter to me.

Charlie wrote:
>
> In article <c8ac4b$2kt4$1@digitaldaemon.com>, imr1984 says...
>
>>I especially dont like member protection
>>because im a bedroom coder so i work on my own, so protecting member variables
>>doesnt really appeal to me.
> 
> I never liked this either, if the getters and setters do nothing more then just
> that ( i.e. they might check a value for a condition etc ) , then why not just
> make the data public ?  Even this month I read an article in favor of getters
> and setters in CUJ, I like python style much better.

While I personally dislike get/set methods I do understand the reasoning behind them.  They are a pre-emptive tactic to enable back-end changes without requiring user-side code changes.  However, properties in D pretty much eliminate the need for this tactic, as there is no semantic difference between public variables and property methods.  It's worth noting that properties have been proposed as an addition to the next version of C++ (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf), probably for this exact reason.

Sean

On Mon, 17 May 2004 15:01:18 -0700, Walter wrote:

> "Charlie" <Charlie_member@pathlink.com> wrote in message news:c8aq9o$94k$1@digitaldaemon.com...
>> I never liked this either, if the getters and setters do nothing more then
> just
>> that ( i.e. they might check a value for a condition etc ) , then why not
> just
>> make the data public ?
> 
> I agree. The common get/set for a simple member variable just looks like clutter to me.

Having public data elements tightly binds modules together. That is to say, if a class's data elements are public it allows code using that class to be dependant on it, thus making it hard to modify the class without breaking already written code.

J. Anderson has mentioned that fortunately, D can help resolve this by using its property technique. Basically, if a public data element needs to be changed in some way by the class author, they can rename the public data element and make it private and create a property with the old name and datatype argument. Then the class author can handle the case where existing code is using the old data form.

Example:

 from...
class Foo
{
   public float XX;
   . . .
}

 to ...

class Foo
{
   private int _XX;

   public XX(float x)
   {
     if (x >= 0)
      _XX = cast(int)x;
     else
      _XX = 0;

   }
   public float XX(){ return cast(float)_XX;}
   . . .
}


-- 
Derek
Melbourne, Australia

On Mon, 17 May 2004 16:46:48 +0000, Charlie wrote:
> I never liked this either, if the getters and setters do nothing more then just that ( i.e. they might check a value for a condition etc ) , then why not just make the data public ?  Even this month I read an article in favor of getters and setters in CUJ, I like python style much better.
> 
> Charlie

That's why they are generally considered a bad idea. If a class is nothing but gets/sets, then it probably should have been a struct. Sure, there's proper uses for them, but when you start writing a lot of them, you should probably examine your design once, just to double check.

Mike Swieton
__
But who prays for Satan? Who, in eighteen centuries, has had the common
humanity to pray for the one sinner that needed it the most?
	- Mark Twain

Derek wrote:
> 
> J. Anderson has mentioned that fortunately, D can help resolve this by
> using its property technique.

Not to quibble, but I said this :)

Sean

"Sean Kelly" <sean@ffwd.cx> wrote in message news:c8bej6$181f$1@digitaldaemon.com...
> While I personally dislike get/set methods I do understand the reasoning behind them.  They are a pre-emptive tactic to enable back-end changes without requiring user-side code changes.  However, properties in D pretty much eliminate the need for this tactic, as there is no semantic difference between public variables and property methods.  It's worth noting that properties have been proposed as an addition to the next version of C++ (http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf), probably for this exact reason.

Someday, C++ may catch up with D <g>.

On Mon, 17 May 2004 16:16:48 -0700, Sean Kelly wrote:

> Derek wrote:
>> 
>> J. Anderson has mentioned that fortunately, D can help resolve this by using its property technique.
> 
> Not to quibble, but I said this :)
> 
> Sean

Sorry, Sean. I was referring to something that J. Anderson wrote in message id <c7pb5h$1lei$1@digitaldaemon.com> on the 11/May. And I quote ...

"
I used to program that way.

With D because of property methods I've found many cases where exposing properties as public is a good thing.  I mean with C++, the convention was to have get/set everywhere.  With D you can convert a property into a method without affecting the outside user (users being the people extending the class or using an instance).

I look at each properties on its own merit and try to decide if an
external user would have any good use for it.  Of  course there are
properties that are unsafe, have some quirky rule or ify (undecided)
which I make private or protected.  They can always be made public
later. I don't make everything public but I look on things from the
other prospective.
"

I was replying to a message from Walter (08:01am in Melbourne, Aus) and it looks as though while I was typing my response, your message came in (8:33am) and I didn't get to read it before sending mine off.

So it seems that there are at least two great D minds. ;-)

-- 
Derek
18/May/04 9:51:18 AM