|
 |
Patrick Elliott wrote:
> the issue isn't semantic, its associative.
I'm not sure what your level of experience with programming is, but such
things stop being problematic after a while.
> Objects don't "usually", when they track some internal set
> of data, rely on purely external sources for storing it, simply because
> that disassociates the data from the object that uses it.
Not if it's indexed by the object.
> ginger.copytransforms(fred)
> vs.
> ginger.applytrandforms(arbitrary_table)
Of course when you name one of them "fred" and the other
"arbitrary_table", it's confusing. Don't do that.
I'm suggesting
walking_transforms[ginger] = walking_transforms[fred].
Or even
walking_transforms[ginger] = feminize(walking_transforms[fred])
or
running_transforms[ginger] = walking_transforms[fred]
Then, eventually, you say
ginger.apply(running_transforms[ginger])
fred.apply(walking_transforms[fred])
If you have a set of global transforms (that always apply), you can
extern function
feminize(array of transforms) returns array of transforms;
global_transforms[fred] = (....)
global_transforms[ginger] = (....)
frame_transforms[fred] = (clock*....)
frame_transforms[ginger] = feminize(frame_transforms[fred])
frame_transforms[freds_arm] = (rotate clock*y)
ginger = object(...)
fred = object(...)
freds_arm = object(....)
foreach object {ginger fred ...) {
object.apply_transform(global_transforms[object])
object.apply_transform(frame_transforms[object])
object.render
}
freds_arm.apply_transform(global_transforms[fred])
freds_arm.apply_transform(frame_transforms[fred])
freds_arm.apply_transform(frame_transforms[freds_arm])
Maybe you should supply a similar bit of pseudo code showing a similar
scene and show why your mechanism is more clear.
> The first one though is "associatively" clearer, even if its
> semantically the same.
Except it only associates to the object. It doesn't "associate" what the
*transform* is, only what object it applies to. Perhaps it's only clear
to you.
Plus, if in your code, you have
ginger.apply(walking_transforms[robot])
fred.apply(walking_transforms[robot])
I think that's more clear than saying
ginger.transforms = fred.transforms
because now you know they're both using the same
transforms and you know those transforms are
treating them both as robots.
> And, even if you wanted to do that, there hasn't
> exactly been a discussion on how you a) structure such a table,
It's structured the same way you'd structure yours, except it's a
user-created object instead of a unique property defined by the
renderer. This also has the advantage that you can (for example) pass it
to user-defined functions without having to create an object just to
carry it around.
> or b) get one out of, or into, an POVRay object that has subobjects.
The same way you would.
> when you first did some_object(<location>,size(s)) Hardly helpful, if
> you are trying to avoid having to redundantly store "every" change
> needed to get from there to the final result.
I think if you want to argue that your syntax is superior to my syntax,
while my syntax is more orthogonal and more flexible yet has similar
semantics,
--
Darren New / San Diego, CA, USA (PST)
Remember the good old days, when we
used to complain about cryptography
being export-restricted?
Post a reply to this message
|
 |