Class vs subroutine

[Rock Ridge Farm (Larry)]

Being an old old C programmer I tend to do things in subroutines.
This causes me issues when I want to reference a class from a subroutine.
In my mind - I build all the screen stuff in classes then do work in subroutines.
My current delima is that I need a progress bar in a subroutine.
Can this be done or do I need to learn more stuff.
I am really having a hard time with classes.

[Protected]

It's the first time I work with a language that mixes functional and object-oriented programming (I never used C++), so I don't know how visible classes and their instances are in subroutines, but if you're having trouble you should be able to use full OOP. Create a class with your main program in it (as if it was in C). Your global main only has to call the main method of that class - maybe you'll have to create an instance of it first, I don't know (are static methods and values supported in Aurora?). Then if you create the classes you want inside your 'main class', you know where they are available at least

[Ionic Wind Support Team]

Currently all methods and member variables are public.   You can pass an address of a class to a function parameter. 

sub StartProgress(MyWindow *wiin,  CProgressBar *bar)
{
      ...
      bar->Create(l,t,w,h,style,999,"",win);

}

But I recommend that you learn a little more about OOP.  A class method IS a subroutine.  One that is associated with that class and has direct access to it's member variables.  Study the frags example.

[Protected]

Are static methods and values supported in Aurora?

[Ionic Wind Support Team]

Not currently.  But we are still not to the beta stages yet and I've been a bit preoccupied.

[Protected]

No problem, I just asked for curiosity 

[John S]

Though I haven't coded much lately, I think I have a handle on Class Concepts.  OOP is a different way of thinking about coding a program.  The following will eventually find itself in the tutorial I started months ago and I will actually write a program based on it.

Basically:

Object Oriented Programming (OOP) puts an emphasis on data objects (data variables),
whereas in Structured Languages the focus of subroutines is more on operations on data variables;

A class is a definition block which can include definitions for data objects (variables) and methods (subroutines);

Class defined data objects (variables) are primarily operated on by methods (subroutines) contained within the class definition.  The concept is that the author of the class understands the data object best and therefore understands the best/safest way to manipulate that data.  This is called "encapsulation" and is a way of protecting data from being corrupted by subroutines outside of the class definition.


A class is not directly used in a program, instead they operate similar to data structures (struct).   The class defines objects and associated methods which are used in a program.

For example, let's say my program defines a class called "Dog" and within my class definition, I define data (variables) such as "Tails", "Legs" and "Color".    To assign the number of tails and legs that the Dog has, I define assignment methods such as "growTail" and "growLegs".  I also want to specify a Color for my Dog, so I create the method "firColor".   The methods (class subroutines) growTail, growLegs and firColor are contained in (encapsulated in) the Dog class and they assign 1 to Tails, 4 to Legs and "brown" to Color.  In this example, I want to not allow the above defined methods to be used outside of my class definition, so I can define them as "private".

Now that my Dog class has been defined, I need to create my Dog object called "Spot".   Spot is a generic Dog without any special features, therefore Spot.Tails = 1, Spot.Legs = 4 and Spot.Color = "brown".   

If for some reason, I'll need to modify the data of my object Spot, such as I want to dock his tail (make Spot.Tails = 0), then I need to create a new method and define it in my class.  In this case, I would define a "public" method called dockTail within my Dog class definition.   Since this new method is "public", I can then use it in my main program by Spot.dockTail().  I can write the dockTail to reduce Tails by one (-1) and test Tails to make sure it doesn't become less than 0.

Now lets say I want to define a new type (class) of Dog which still has lots in common with other "Dog"s, but always has floppy ears and is black.  I can either define a whole new class from scratch, or better yet, I can define a "child class" which "inherits" attributes from the parent class.  If I go the inherittance route, I can define a new subclass of Dog called "BlackLabrador" and include in blackLabrador a boolean variable called "FloppyEars" which is assigned True (1) by an new private method called makeEarsFloppy().  I also can redefine firColor() to assign "black" to Color

In my main program, I can create a new object called Skippy which is a BlackLabrador which is a Dog.  Skippy.Tails = 1, Skippy.Legs = 4, Skippy.Color = "black" and Skippy.FloppyEars = True (=1).

I was reminded that Aurora is still in alpha and doesn't yet offer "private" methods.  So for now at least all methods are public.
Aurora has come a very long way in a relatively short time.  Hat's off to Paul. 

Tonight,  I'll try to code this little example.  In its first incarnation, it will be strickly a console text based example, then I will use the text to a window.  Lastly, I will try to draw the dogs using the 2d stuff   

[John S]

Larry,
I've been working on my tutorial again, this time I'm tackling OOP. 
The attached code samples reflect the discussion I wrote above (without the tail docking).  I also added Retriever and WorkingDog classes

( Major edits to suit Paul's comments (thanks Paul) )

Code Select Expand


//  MyDog.src - to be compiled as a console executable

#include "Dog.inc"
#include "Retriever.inc"
#include "WorkingDog.inc"

global sub main
{
  Dog Spot;
  Spot.giveName("Spot");

  WorkingDog RinTinTin;
  RinTinTin.giveName("RinTinTin");

  Retriever Skippy;
  Skippy.giveName("Skippy");

  Spot.OutPutToScreen();
  RinTinTin.OutPutToScreen();
  Skippy.OutPutToScreen();

  writeln ("\npress any key\n");
  while (GetKey() == "");
  return;
}


Code Select Expand


//  Dog.inc
//  This include file provides the Dog Class
//  Dog has basic attributes of the Dog Class

class Dog
{
  int Tails, Legs;
  string Color, Name, Ears;

  declare  Dog();                       // Dog constructor
  declare _Dog();                       // Dog destructor

  declare giveName( string somename );
  declare growTail();
  declare growLegs();
  declare virtual firColor();
  declare virtual growEars();

  declare OutputToScreen();
}

Dog::Dog()
{
  writeln("\nDog constructor has been called\n\n");
  growTail();
  growLegs();
  growEars();
  firColor();
  return;
}

Dog::_Dog()
{
  writeln("Dog destructor has been called\n\n");
  return;
}

Dog::growTail()
{
  writeln("Dog grows a tail\n");
  Tails = 1;
  return;
}

Dog::growLegs()
{
  writeln("Dog grows legs\n");
  Legs = 4;
  return;
}

Dog::firColor()
{
  writeln("Dog grows fir\n");
  Color = "brown";
  return;
}

Dog::giveName( somename as string )
{
  writeln("your Dog is named\n");
  Name = somename;
  return;
}

Dog::growEars()
{
  writeln("Dog grows ears\n");
  Ears = "pointed";
  return;
}

Dog::OutPutToScreen()
{
  writeln ("\n\n");
  writeln ("\n     the name of my dog is " + Name);
  writeln ("\n     my dog has " + str$(Tails) + " tails");
  writeln ("\n     my dog has " + str$(Legs) + " legs");
  writeln ("\n     my dog's fir is " + Color);
  writeln ("\n     my dog has " + Ears + " ears");
  writeln ("\n\n\n");
}


Code Select Expand


//  Retriever.inc - must be included after Dog.inc
//  This include file provides the Retriever Class which is a child of the Dog Class
//  Retriever inherits attributes from Dog

class Retriever : Dog
{
  declare growEars();
}

Retriever::growEars()
{
  writeln("The Retriever grows ears\n");
  Ears = "floppy";
  return;
}


Code Select Expand


//  WorkingDog.inc - must be included after Dog.inc
//  This include file provides the WorkingDog Class which is a child of the Dog Class
//  Working Dog inherits attributes from Dog

class WorkingDog : Dog
{
  declare firColor();
  declare growEars();
}

WorkingDog::growEars()
{
  writeln("Working Dog grows ears\n");
  Ears = "pointy";
  return;
}


[kryton9]

I am trying to understand classes and came up with a question/example that I think will help me understand it better. Can someone take my sudo structure and first see if my thinking is correct. If so, then to just show it in a code skeleton.

I thought a universal system would be perfect to understand it all. That galaxys, suns, planets and moons, but in thinking of that then thought well would there be a universe class?

So my current understanding is this:

Class Universe
ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, location x,y,z,time
ÂÃ,  ÂÃ, sub class galaxy
ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  location relative to universe x,y,z
ÂÃ,  ÂÃ, sub class sun
ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, location relative to galaxy x,y,z
ÂÃ,  ÂÃ, sub class planet
ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, location relative to sun x,y,z
ÂÃ,  ÂÃ,  sub class moon
ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ,  ÂÃ, location relative to planet x,y,z

or would there just be one unviverse class and no such things as sub classes? As you can see really confused

[John S]

Did you look at my post just above yours?  No need to declare "sub class".  Use the : operator

class Universe
{
  float x,y,z,t;

  declare  Universe();                       // constructor
  declare _Universe();                      // destructor
}

class Galaxy : Universe                     // Galaxy is a "sub-class" of Universe
{
  // declare some data and methods
}

class Sun : Galaxy                     // Sun is a "sub-class" of Galaxy
{
  // declare some data and methods
}

...

[kryton9]

Thanks for your reply John. I did look at your post and that is why I posted in this thread. Thanks for your example, but I got confused looking at it... getting old I guess.

So for the universe you would make sub classes and not just have one class called universe and put everything in there?

That is where I confused. Not sure where you go sub class or just one class?

[Ionic Wind Support Team]

First lets get the terminology straight.  It is not a "subclass" which is something else entirely.   In OOP you have base and derived classes.  A derived class inherits all of the functionality of the base class, which means it is a "kind of" the base class.

This discussion from a while back with Docmann should help you a bit.

http://www.ionicwind.com/forums/index.php?topic=292.45

Look towards the end.

I always tell new oop programmers to just think of a class as a structure (UDT) that has functions (methods) built in.  Which is not far from the truth as a class object is a structure in regards to its member variables.

Paul.

[Parker]

As an interesting anecdote... with java as the college board requirement now, anyone who takes programming for one year and decides later to start back as a hobby, we'll have to explain to them, "A structure is just like a class but with no methods"

[Haim]

Just a logic remark - universe is the ancestor of everything, it cannot have a location as all derived classes have location vectors relative to universe...