Shop OBEX P1 Docs P2 Docs Learn Events
Object Instances — Parallax Forums

Object Instances

GoogGoog Posts: 65
edited 2006-06-25 04:47 in Propeller 1
I've been looking for information on how objects are shared between other objects - is this possible?

For example:
Object1 creates ObjectA.
Object1 creates ObjectB.
ObjectB would like to use the same instance of ObjectA created in Object1, without creating a new object and thus using more memory.

I just can't find how, but I think it might be possible with pointers?

A good example would be where the parent object uses the graphics object, but a child would also like to use the same graphics object.

Thanks,
Goog


▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

Doing my part to keep the Commodore 64 alive!

http://www.commodorestuff.com
·

Comments

  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-06-22 17:54
    Goog,

    ·· An object can launch a part of itself into other COGs using the COGNEW command.· If you have a Method called "BLINK" in your object, you can launch multiple instances of it by doing something like this:

    COGNEW(BLINK, @stack)
    

    Of course you have to have defined stack space for it.· You can call this as many times as there are cogs available, but each will need stack space for itself.


    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • GoogGoog Posts: 65
    edited 2006-06-22 19:52
    Thanks for the reply, Chris, but I understand this possibility.· What I really need to do is to send a reference (for example) of Object B, which was created from Object A to Object C.· That way, Object C can use the same instance of Object B that A uses.

    Think of this possibility: My parent object does all of the graphics display, but the child object wants to do some drawing as well.· Without sharing the graphics object, the compiler allocates enough memory for the parent and the child's graphics objects, basically doubling the amount of space used.· What I would like to do is something like this:
    (Object A)
    OBJ
         objGraphics : "graphics"
         objObjectB  : "objectb"
     
    PUB Start
      objGraphics.Start
     
      'Pass a reference of this object to object B
      objObjectB.Start(@objGraphics)
     
     
     
    (Object B)
     
    OBJ  objGraphics : "graphics"
     
    PUB Start(GraphicsObj)
     
      'Need something like this:
      objGraphics := GraphicsObj
     
      ...do graphics drawing here or in other procedures...
    

    Any thoughts?

    Thanks,
    Goog

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
    ·
  • acantostegaacantostega Posts: 105
    edited 2006-06-23 05:12
    I'm wondered about this as well. For example, what if I need to debug several objects running concurrently using one serial port? Of course there would be concurrency issues:, but they could be dealt with with semaphores. Is it necessary to pass object references? Maybe the serial object object is globally visible? Unfortunately I'm away from home for the week so I'm not able to try this out.
  • JavalinJavalin Posts: 892
    edited 2006-06-23 11:13
    I've been doing this (spi & i2c) - and the only issue I have found is where you run this "multi-cog".

    I.e cog0 and cog4 both "run" the same code. It is fine as long as both dont try to do stuff at the same time, and you have to pay attention to the multi-cog pin control rules. Basically always release the pins to Input mode in the objects.

    Have a look at the i2cObject in the library.

    James
  • GoogGoog Posts: 65
    edited 2006-06-23 18:26
    I couldn't find any example in the I2C code that re-uses the same object in all of the child objects. Doesn't each child module reference a new instance of the I2C object? Am I missing something?

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
    ·
  • Chris SavageChris Savage Parallax Engineering Posts: 14,406
    edited 2006-06-23 19:06
    Goog,

    ·· I still don't think I know exactly what you mean, but when you launch multiple copies of the same object, they don't use more memory for each instance...The only extra space used is the Stack and Variable space.· The actual Object only exists once in main memory for SPIN objects.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Chris Savage
    Parallax Tech Support
    csavage@parallax.com
  • GoogGoog Posts: 65
    edited 2006-06-23 19:16
    Sorry I'm not being clear... OK, I'll see if I can play around and come up with some actual code to share so we can be in sync... stay tuned.

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
    ·
  • GoogGoog Posts: 65
    edited 2006-06-23 19:56
    OK, here is my example.· You should be able to read through the code and figure out what is going on - I commented it clearly (I hope).

    Basically, in the end, ChildB should display the same LEDs as the parent did, but instead they are all off (because ChildB reads the value and gets a return of zero).· You'll understand when you see/run it.·

    So this is what I'm trying to accomplish - using a child object that references another object created by its parent.

    Goog

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2006-06-23 20:11
    Goog,

    VARs are duplicated for each instance of the object. If you want instances to share the same data, put it in a DAT section, like this:

    'ChildA object
    ' This object is used by Parent as well as by ChildB.
    
    [b]PUB[/b] Start(InitValue)
    
      lngInitialValue := InitValue
    
    
    [b]PUB[/b] ReadValue  
      
      [b]Result[/b] := lngInitialValue
    
    [b]DAT[/b]
    
    lngInitialValue         [b]long[/b]      0
    
    
    



    -Phil
  • GoogGoog Posts: 65
    edited 2006-06-23 20:20
    Thanks Phil! That certainly worked. WOO HOO! I think this is it. [noparse]:)[/noparse]

    So basically, the VAR section has "private" variables that are only accessible by the parent object? And the DAT section has data/variables that are global to the object - the values stay the same until changed by any object anywhere in code? (it seems so, but I would like solid confirmation)

    Goog

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
    ·
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2006-06-23 20:48
    Goog,

    Close, but not quite. The VAR section consists of variables that are duplicated for, and unique to, each "instance" of the object. (I use the word "instance" loosely, since the object itself is not duplicated — only its environment data are, including its VARs.) VARs are not shared with other instances of the same object or with any other object, including the parent. Variables in the DAT section, like the object they're contained in, have only a single copy in hub RAM. You can think of them as part of the object's code (that doesn't get duplicated), if you like. These data are therefore shared by all "instances" of the object, since they're part of the object itself.

    -Phil
  • GoogGoog Posts: 65
    edited 2006-06-23 21:03
    Oops - I misspoke... I didn't mean to indicate that VARs are "private", accessible by parent object, but rather that they are created/initialized within the scope of the object (parent) who created it. I realize VARs are private only to the object where they are contained (just like you said). Hope I didn't confuse anyone!

    Hopefully this will be explained more in detail in the final version of the manual - I only found limited information regarding object instances, which is why I started this whole topic.

    Thanks!
    Goog

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔

    Doing my part to keep the Commodore 64 alive!

    http://www.commodorestuff.com
    ·
  • acantostegaacantostega Posts: 105
    edited 2006-06-24 21:14
    It seems to me that the DAT memory acts somewhat like static class members in C++ and Java. Is this right?
  • CJCJ Posts: 470
    edited 2006-06-24 21:42
    I think we may be working with unintended DAT activity, let's all keep up the creativity

    ▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
    Who says you have to have knowledge to use it?

    I've killed a fly with my bare mind.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2006-06-24 21:43
    It probably won't be helpful to compare Spin's "objects" to those in true object-oriented languages. The parallels are scant, at best; misleading, at worst. What is called an object in Spin might best be referred to as a "class" instead, if it were only possible to create objects that could invoke methods in the class, which it's not. The term "object" was the subject of a lively and protracted debate among the beta users. For a moment, it looked like the term "module" might prevail, since it better describes what a Spin object really is and doesn't entail all the baggage that "object" carries with it. But too much had already been invested in the word "object" to change it.

    -Phil
  • acantostegaacantostega Posts: 105
    edited 2006-06-25 04:47
    Yes, and not to mention inheritance, polymorphism and such... But who needs all that for a microcontroller. I at least don't care that much for OO (I program mainly in C and lisp). What I meant is that there is only one copy of the DAT items for all instances of the class, so they might have some of the functions of the static data members in C++/Java, like a common workspace for communicating info among instances.
Sign In or Register to comment.