ok i see no reason why the with() statement shouldnt work with structs. Logically it makes more sense for with() to only work with structs because you tend to access structs using their member variables directly, much more than you do with classes.

I also think that structs should be able to inherit from member only base structs.

And access protection should work for structs too.

So the only advantage that classes should have is polymorphism.

thats what i think anyway

imr1984 wrote:
> ok i see no reason why the with() statement shouldnt work with structs.
> Logically it makes more sense for with() to only work with structs because you
> tend to access structs using their member variables directly, much more than you
> do with classes. 

In the future with() might work with structs. I think Walter has mentioned that it's possible.

> 
> I also think that structs should be able to inherit from member only base
> structs.
> 
> And access protection should work for structs too.
> 
> So the only advantage that classes should have is polymorphism.
> 
> thats what i think anyway
> 
> 


-- 
Justin
http://jcc_7.tripod.com/d/

imr1984 wrote:

> ok i see no reason why the with() statement shouldnt work with structs.
> Logically it makes more sense for with() to only work with structs because you
> tend to access structs using their member variables directly, much more than you
> do with classes. 

I agree.

> I also think that structs should be able to inherit from member only base
> structs.
<snip>

Agree to the extent that it would save defining unions of structs to wrap API structs.

Further, such a struct, in which only methods are added, could be implicitly convertible to/from its base.  Whereas one that adds fields to the struct (if we should allow such a thing) wouldn't.

Stewart.

-- 
My e-mail is valid but not my primary mailbox, aside from its being the unfortunate victim of intensive mail-bombing at the moment.  Please keep replies on the 'group where everyone may benefit.

imr1984 wrote:

>ok i see no reason why the with() statement shouldnt work with structs.
>Logically it makes more sense for with() to only work with structs because you
>tend to access structs using their member variables directly, much more than you
>do with classes. 
>
>I also think that structs should be able to inherit from member only base
>structs.
>
>And access protection should work for structs too.
>
>So the only advantage that classes should have is polymorphism.
>
>thats what i think anyway
>
>  
>

I agree to.  I like structs because they are light.  I hate structs because they are not reusable.  I've come up against this problem over and over again.

-- 
-Anderson: http://badmama.com.au/~anderson/

J Anderson <REMOVEanderson@badmama.com.au> wrote:

> I agree to.  I like structs because they are light.  I hate structs because they are not reusable.  I've come up against this problem over and over again.

In my first programming efforts with D (converting a simple text game), the main problem with structs that I ran into was not having constructors.  In C++, I routinely used these to initialize structs:

Point p = Point(10, 20);

As I understand D so far (and I am only a grasshopper), this now takes three lines:

Point p;
p.x = 10;
p.y = 20;

-- 
dave

Dave Sieber wrote:

>J Anderson <REMOVEanderson@badmama.com.au> wrote:
>
>  
>
>>I agree to.  I like structs because they are light.  I hate structs because they are not reusable.  I've come up against this problem over
>>and over again.
>>    
>>
>
>In my first programming efforts with D (converting a simple text game), the main problem with structs that I ran into was not having constructors.  In C++, I routinely used these to initialize structs:
>
>Point p = Point(10, 20);
>
>As I understand D so far (and I am only a grasshopper), this now takes three lines:
>
>Point p;
>p.x = 10;
>p.y = 20;
>  
>

This type of construction can be written in a method or a free function.  I don't have much of a problem with constructors.  Mainly inheritance.

-- 
-Anderson: http://badmama.com.au/~anderson/

Point p = { x:10, y:20 };

-C. Sauls
-Invironz

Dave Sieber wrote:
> J Anderson <REMOVEanderson@badmama.com.au> wrote:
> 
> 
>>I agree to.  I like structs because they are light.  I hate structs because they are not reusable.  I've come up against this problem over
>>and over again.
> 
> 
> In my first programming efforts with D (converting a simple text game), the main problem with structs that I ran into was not having constructors.  In C++, I routinely used these to initialize structs:
> 
> Point p = Point(10, 20);
> 
> As I understand D so far (and I am only a grasshopper), this now takes three lines:
> 
> Point p;
> p.x = 10;
> p.y = 20;
> 

"C. Sauls" <ibisbasenji@yahoo.com> wrote:

> Point p = { x:10, y:20 };

Wow! How did I miss that? :-)  Ok, it's only been two days, I have a lot to learn.

After I wrote that earlier reply, I realized that it was mostly in function calls that I was doing something like that, e.g.

object.moveTo(Point(10, 20));

I was converting some C++ code which used this kind of call frequently. Anyway, there are numerous ways to achieve the same result, including modifying, in this case, moveTo() to take the arguments directly, as an overloaded variant:

object.MoveTo(10, 20);

-- 
dave

Comments imbedded: (who started this phrase-trend, btw?)

Dave Sieber wrote:
> "C. Sauls" <ibisbasenji@yahoo.com> wrote:
>>Point p = { x:10, y:20 };
> Wow! How did I miss that? :-)  Ok, it's only been two days, I have a lot to learn.

Happens to me constantly, don't worry about it.

> object.moveTo(Point(10, 20));

In that case, you could always do:

<snip>
// ...
struct Point {
  int  x,
       y;

  static Point opCall(int xx, int yy) {
    Point p = { x:xx, y:yy };
    return p;
  }
}
// ...
object.moveTo(Point(10, 20));
// ...
</snip>

I forget who posted this idea before... credit to whomever it was. Guess I could be non-lazy and search for it... but alas, lazy I am.

-C. Sauls
-Invironz

"C. Sauls" <ibisbasenji@yahoo.com> wrote:

> In that case, you could always do:
> 
> struct Point {
>    int  x,
>         y;
> 
>    static Point opCall(int xx, int yy) {
>      Point p = { x:xx, y:yy };
>      return p;
>    }
> }
> // ...
> object.moveTo(Point(10, 20));
> // ...
> </snip>

Thanks again, another new feature I've learned -- I had used opCall, but hadn't thought about using it with a struct.

BTW, one minor point: I can't initialize the Point as you wrote it above, the compiler complains that p isn't static. No biggie -- a slight adjustment, and it's all working, in particular the moveTo(Point(10, 20)) expression.

And -- I got the game (my first project, converting an old C++ app to D) converted, compiled, and running! Intense, I've been on it all day (one benefit of being unemployed :-)  Many, many compile errors, access violations, array bounds errors -- you name it. And a lot of help here, so thanks to everyone for being so helpful. Still a couple screen boo-boos in the game, but they are cosmetic.

I've also got WinDbg working, to locate the Access Violations, and I wrote some logging routines as well, to help track where the problems were (couldn't use printf() because of the game screen). A good learning experience so far, but I do wish for better debugging. A line number for access violations/exceptions would be nice, in debug builds when it is available. Would have helped a lot -- we have them for array bounds errors and switch/case default errors, so I think it should be doable...?

-- 
dave