PDA

View Full Version : Does struct have "self" concept...


RustyKnight
04-29-2008, 04:57 AM
Basically I want to know if a struct has a concept simular to "self" or "this" that will point to itself (from within the struct) so that I can do something like...

ieConsumer = undefined
stuct FoodOps (

fn feed = (

Consumer.eat <this>

)

)

struct ConsumerOps (

fn eat food = (

-- Expecting a food struct here

)

)

Consumer = ConsumerOps()

SomeFood = FoodOps()
SomeFood.feed()
Shane

JHN
04-29-2008, 09:55 AM
AFAIK, there's no self or this in a struct.
But you could use the struct name if you instance it with the same name as the struct def is named.


Consumer = undefined

struct FoodOps (

fn feed = (

Consumer.eat FootOps

)

)

struct Consumer (

fn eat food = (

-- Expecting a food struct here

)

)

Consumer = Consumer()

FoodOps = FoodOps()
FoodOps.feed()



But it doesn't make a lot of sense (IMHO) to take this route... wouldn't the consumer need a eat method? Why would an object feed itself to another object, to me it makes more sense if the consumer object has an eat method (love the analogy) and then you pass the food object to that method... that way bypassing the missing self/this...

Another way to have a self or this is to define a unique global variable that you pass into a variable of the instanced struct. Take a look at the rollout creator script, it uses a similar method.

My 2 (euro!)cents,
Johan

RustyKnight
04-29-2008, 11:19 PM
Hi JHN! That's an interesting idea, I'll have to look into it. Unfourtantly it won't fit my model, I'll have more then one "product" struct.

I've been doing OO for the past couple of weeks and I think I'm over enginerring this problem, but the idea I've thought of is to have the "factory" set a variable in the "product" struct that points to itself, thus...struct Producer (

fn produce = (

local p = Product()
p.this = p

p

)
)This will work for what I want to do, the only danger is if someone instansitates the Product struct themselves...but with any luck, that won't happen :P

Cheers
Shane

ps - Oh for OO maxscript...

davestewart
05-01-2008, 06:48 PM
Hey Shane,

Just checking your ponderings. I was playing with something like this a couple of years ago, and it's an intersting one. It does smack of square peg and round hole a bit somewhat.

So once you have your self-referencing struct, what sort of things are you planning on doing with it? As Johan said, your OOP structure was a bit backwards (I get that your example was somewhat hypothetical), so I'm interested to know why you wanted to do it in the first place.

I'm just interested, that's all ;)

Cheers,
Dave

RustyKnight
05-01-2008, 09:46 PM
Hey Shane,

Just checking your ponderings. I was playing with something like this a couple of years ago, and it's an intersting one. It does smack of square peg and round hole a bit somewhat.

So once you have your self-referencing struct, what sort of things are you planning on doing with it? As Johan said, your OOP structure was a bit backwards (I get that your example was somewhat hypothetical), so I'm interested to know why you wanted to do it in the first place.

I'm just interested, that's all ;)

Cheers,
DaveHi Dave!

Foregive my ambaguity, while the project I'm working on is a personal one, it is not ready for public release ;)...

Basically, I'm working a mechanism to import and process multiple data files. Each data file may contain 0-n references to other data files which need to be included. This quickly adds up to hundreds, perhaps, thousands of data files been loaded (each containing numerous lines of commands that need to be processed). Thankfully, some of this can be cached.

What I want to do is implement the core loading and processing functions into a single instance of the a struct (the factory) so max didn't need to maintain (potentionally) thousands of references to the same code...trying to optimise here.

But the problem is, the factory function I designed requires a reference to the child structure...

Okay, this really isn't a massive problem, but I simply wanted to design the solution in such away that the start point for the processing was the child stuct itself, not the Factory...child = factory.load()
child.process() -- Child will eventually call Factory.process child

In OO, I probably would have designed a interface or abstract implementation of the core functionality and built upon it, this would have provided the optimisation I was looking for. Here I need to do something a little bit more "weird".

I want to provide a number of different levels of interaction with the datafiles. I want to be able to "visually" step through the data file code, making a tree of the data perhaps, as well as physically process the data in realtime, hence the number of levels of abstraction I'm going to do.

I've ALMOST got the "base" engine ready, so I hope I will be able release soon...but given I've been working on it on and off for a month or so, that might be a little optimistic...;)

Shane

davestewart
05-01-2008, 10:16 PM
Hey Shane,
Thanks for the explanation!

Sounds similar-ish to what I was doing - I wanted to be able to create a modular struct that could be self referenced to create hierarchies, and let you navigate up and down and such like.

I'm not even sure if this runs, but I did a quick search on my hard drive to grab whatever it was I was tinkering with.

struct tree
(
data = "",
parent = undefined,
children = #(),
function addChild pNode data =
(
cNode = tree data:data
cNode.parent = pNode
append children cNode
return cNode
)
)

branch1 = tree data:"Top Level"
branch2 = branch1.addChild branch1 "Level 1"
branch3 = branch2.addChild branch2 "Level 2"

print branch1.data
print branch2.data
print branch3.data
print branch3.parent.data

branch1.children[1].parent == branch1

Not sure how I'd tackle this now, perhaps I'd use the MSXML control or something...

Keep us posted anyway!

:D

PS. The factory approach sounds like a good one. I'm more up on OOP these days, I even do a bit of reading on design patterns when the mood takes me... ha!

3rd Dimentia
05-02-2008, 12:33 AM
Along the same lines as this thread, is there a way, in a maxscript controller to access "self" without having to explicitly give the name like $sphere01?

Cg.

JHN
05-02-2008, 01:27 PM
A script controller has a "this" variable, but it points to the script controller itself not the object it's applied to. You could get the object by using ref.dependents, but I don't know what happens with instanced controllers or objects...

You can also use the weak reference of the assign node function and use self as the name of the node...

-Johan

Jon-Huhn
05-02-2008, 02:29 PM
Sorry if this was posted already, I just took a brief glance at the existing responses and didn't see this techniqe, so I'll post it now. This code will create a struct with a self-referencing "This" variable.




struct myStruct (This,

fn init selfRef = This=selfRef

)

local StructInstance=myStruct()
StructInstance.init StructInstance



So basically whatever code instantiates the struct also needs to pass the reference of the instance to itself for storage.

Jon-Huhn
05-02-2008, 02:37 PM
Also, if you were loading many of these types of data structures externally, you could package each struct inside of "()", and then save that in a seperate .ms file to be loaded with fileIn(). This way, the struct instance that's returned by the fileIn() command already contains a nifty self-reference.

CGTalk Moderation
05-02-2008, 02:37 PM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.