Mark R. Jonkman wrote
On the issue of the QTObject, I truely believe that any
object that directly controls a sprite should take complete
and full control of that sprite and that the sprite
essentially becomes one with the object with the sprite's
properties becoming private to that object
very well written Luke.
this is the stumbling block between the article my use of OOP in
Director.
There may be a fine line between passing data in a
parameter (such as the percentage of the movie played) and a
blunt heres my
private data for anyone that asks type accessor, but surely
Al Hospers wrote
perhaps it is, as Colin K says, a matter of semantics. I think I said
that in about the middle of the thread. and Director's current mixed
OOP/procedural state makes it difficult to define the boundaries some
times.
Hi Al,
OOPs and semantics seem to tango a lot :)
I think
At 6:34 PM +1000 8/22/01, Luke Wigley wrote:
I agree with Mark. The difficulty for me is establishing effective lines of
communication between the various objects that respect the principles that
accessors tend to indicate sloppy encapsulation, and that 'mutual references
are evil'.
Leaving
At 21:22 -0400 2001_08_20, Al Hospers wrote:
if you end up putting the slider code inside the
QTBehavior it starts to become almost like procedural code. you have
this large bunch of code that becomes difficult to maintain that has
everything in it including the kitchen sink. what is the point?
if you end up putting the slider code inside the
QTBehavior it starts to become almost like procedural code. you
have
this large bunch of code that becomes difficult to maintain
that has
everything in it including the kitchen sink. what is the point?
Exactly! What is the point?
Where did
but he is saying that you should not get data from an object. if you
do that is accessing the data and is verboten. correct?
Incorrect. As I mentioned before he is saying access private data is a
no-no. Even in his ATM example he is showing data exchanging between
objects, it's just that none
I think the problem is a matter of semantics... I believe
that by accessor
methods we simply mean a method that gets or set another
objects properties.
By contrast, a method that returns data that is not private
to an object is
*not* classified as an accessor method. I do not know if this
Mark made great explanation of an OOP structure.
However, reading it only makes me nod, it doesn't make me shake my
head, or feel dizzy, and that was sort of my expectation, from all
the fuzz.
Maybe there's an important mental difference in calling a method
handle something, rather than set,
At 15:34 -0400 2001_08_21, Al Hospers wrote:
...and in fact based on Jakob's response this AM I might say
that there may still be some confusion out there. grin
You betcha! Confusion is my middle name.
Regards, Jakob confusion Madsen.
[To remove yourself from this list, or to change to digest
and you can pass information to an
object, as long as what you are passing does not correspond to an
actual property of an object, then I definitely understand.
That is correct.
It doesn't matter.
The method is public, and whether it implements itself by fetching
private data, or
Jakob made a lot of good points, and boiled it all down to:
Suddenly it seems so cloudy again... can you wipe away the clouds?
This is where I usually end up whenever I try to adhere religiously to pure
OOP standards in Director. I just get the feeling that the hybrid
procedural/oop
Hi Jakob
Mark made great explanation of an OOP structure.
However, reading it only makes me nod, it doesn't make me
shake my
head, or feel dizzy, and that was sort of my expectation,
from all
the fuzz.
Darn.. you mean I didn't totally put you to sleep.. drats..
I'll have to try harder the next
Al Hospers (and others) wrote:
OK,
A bunch of different messages on this topic
Sorry, I've been working on other stuff, and finally have a chance to
jump in here. A couple of things ...
I think the article that was originally cited here is very good.
However, it is slanted toward the Java
Irv,
glad to hear ya...
There are a lot of messages on this thread and I've just skimmed
most
of them. I've been trying to understand where Al is going when he
is
talking about a global QuickTIme object and a global Slider object.
Maybe I'm missing something, but wouldn't this make more
At 4:03 PM -0400 8/20/01, Al Hospers wrote:
Irv,
snip
yes. in my last post I said that both should be behaviors in this
example. at first I was trying to talk about this as an object just
for the sake of argument. then I realized that this was getting
confusing so I just stripped it down to
The basic idea of an accessor is that it is a specialized method
which just gets or sets a property variable within an object, like
this:
SNIP
yes, I write things like this all the time.
The author of the article was basically saying that methods like
these above should never be written
hi Mark,
There is no need for a get/set situation, your passing a
useable parameter and allow the other object class to deal
with it as it sees fit. What happens within the other object
is non of the message senders business. In this manner, you
still communicate but you pass simple values
I think Mark did a great job of explaining it here. The key is that
QT behavior just broadcasts a message about the percentage completion
of the QT movie, and the receiver (the slider behavior) does whatever
it needs to do to represent that amount of completion. The slider
behavior could be
Maybe the problem is a conceptual one. The 'idea' of an
accessor method ties
you into the 'idea' that here is my data -- do with it
what you will.
Yes! Spot on! Accessors (of the get or set variety) are
problematic in that
they tempt lazy encapsulation.
That's not to say you can't use
Brennan Young wrote:
Al Hospers [EMAIL PROTECTED] wrote
so a slider function should only be passing the current slider knob
location as a % of the slide. thus it could be used for anything that
would use a slider, not just QT! OK, that's good.
Perhaps not even a percentage. When the
I don't think the issue is whether objects can pass data or
not... Surely
they must otherwise there would be no communication between
any of your
objects. I think the issue is should they pass private data to another
object via a getter method.
I've been following this thread with a
OK,
it seems we coming to an agreement that to enable meaningful
encapsulation there must be the ability to perform data exchange
between an object and the external environment, that may include other
objects. in order to exchange data you can:
1 - directly manipulate the data
2 - make the
Snip Al's post
what do you think?
I absolutely agree with everything you just said :)
Karina
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL PROTECTED] (Problems, email [EMAIL
Al Hospers wrote:
3 - make it accessible via an accessor method
thus we are left with item #3 which alllows the object to control the
format of the data being accessed and while not perfect, is certainly
the lesser of 3 evils.
what do you think?
I'm jumping into this discussion a bit
Absolute concurrence here - I suppose the main requirement of the
accessor methods is to supply/set the data required in such a way that
the object can be perceived as a black box. ie you should be able to
change the implementation of the method without affecting any other
objects
At 9:06 -0400 2001_08_17, Al Hospers wrote:
2 - make the data public by making it a global variable
I don't see where these globals come creeping in?
In Lingo you can always access the properties of an object directly,
but you decide not to do it.
3 - make it accessible via an accessor method
At 16:19 -0700 2001_08_16, Colin Kettenacker wrote:
I think the key issue is:
No matter how convoluted you make the structure, to avoid having a
getter method in the qtObject, you will either wrap the
slider-code
inside the main qtObject, or accept passing data from one object and
1 - directly manipulate the data
2 - make the data public by making it a global variable
3 - make it accessible via an accessor method
Maybe the problem is a conceptual one. The 'idea' of an accessor method ties
you into the 'idea' that here is my data -- do with it what you will.
Perhaps
Karina Steffens [EMAIL PROTECTED] wrote
The way I see it, the moment you define an accessor method in your object,
you automatically declare the property it accesses as public. That's the big
difference. You don't just grab any old property from an object, as you
would with direct access,
In the Quicktime wrapper example, I see no reason why the
slider should
'know' about the Quicktime movie, and I see no reason for the
QT wrapper to
know how 'progress' is expressed by the object it calls back,
which might
just as well be a field displaying an integer.
If the slider is
2 - make the data public by making it a global variable
I don't see where these globals come creeping in?
In Lingo you can always access the properties of an object directly,
but you decide not to do it.
I was just putting all of the options on the table.
3 - make it accessible via an
At 13:43 -0400 2001_08_17, Al Hospers wrote:
But an essential focus of the original discussion was about *not*
using getters ie. data requisition methods.
I may spawn confusion with some misinterpretation, I'm just trying
to
understand the article.
I recommend reading the article.
We could try to follow a convention without getters, and set up
the
structure so that the objects sends data to each other.
I still think the aggregate model, with the video as a main
meta-object potentially possessing a slider subObject, is a robust
model.
The video tells the slider where
OK,
I just read the article. good one BTW, even if I think he's just a
bit, shall I say, opinionated. grin but that is fine. so here is his
ATM example:
===
An object-oriented ATM system just models the earlier problem
statement. Here's the message flow:
The user (Bill) walks up to an
I've been following this thread with a certain amount of puzzlement, but
here you completely lost me...
Sorry 'bout that. I've been really under the gun this week so my
explanations have not been as full bodied as I would like them to be.
The way I see it, the moment you define an accessor
1 - so how would a slider behavior know what object to talk
to? would
you enter the global reference to the QTObject in the
getObjectProperties dialog?
I must of missed a previous post what do you mean by
getObjectProperties.
what I meant is the propertyDescriptionList you can get when
Al Hospers [EMAIL PROTECTED] wrote
so a slider function should only be passing the current slider knob
location as a % of the slide. thus it could be used for anything that
would use a slider, not just QT! OK, that's good.
Perhaps not even a percentage. When the slider 'registers' to be a
Ken Prat [EMAIL PROTECTED] wrote
Maybe the problem is a conceptual one. The 'idea' of an accessor method ties
you into the 'idea' that here is my data -- do with it what you will.
Yes! Spot on! Accessors (of the get or set variety) are problematic in that
they tempt lazy encapsulation.
This sounds like the book I've been looking for, you don't have an ISBN
for it do you?
Pete
On Thursday, August 16, 2001, at 12:58 AM, Mike Nardell wrote:
I would like to join in on this thread; in particular I would like to
know
if anyone has thought about using the patterns approach in
Item 1 - instantiation would probably (and most importantly)
cache values
such as movie duration, so we might need to have a special
handler which
does this more than once for those situations where we swap
the member.
Special handler? Aha. Warning bells ring in my head. (See below)
Item 1 - instantiation would probably (and most
importantly) cache values
such as movie duration, so we might need to have a special
handler which
does this more than once for those situations where we swap
the member.
Or another object that manages swapping of the members.
dunno.
It appears, that his dogma could also be described as never pass
data between objects.
I suspect that he is somehow beating around the bush, and avoids
mentioning the levels at which data will necessarily start flowing
between objects. His let the textObject do its own rendering into
the
Hi -- Um ... under a pile of books on my desk lies my copy of _Design
Patterns_. (The book tends to migrate in the stack from the top of the stack
to the bottom, depending on what state of program development I am engaged
in)
_Design Patterns, Elements of Reusable Object-Oriented Software_
Erich
Ahem, are you exploring new boundaries of purist OOP, and at the same
time considering globals???
Let alone, that from a practical point of view, it would obstruct
multiple simultaneous instances.
I think the key issue is:
No matter how convoluted you make the structure, to avoid having a
This sounds like the book I've been looking for, you don't have an ISBN
for it do you?
ISBN: 0201633612
Cordially,
Kerry Thompson
[To remove yourself from this list, or to change to digest mode, go to
http://www.penworks.com/LUJ/lingo-l.cgi To post messages to the list,
email [EMAIL
Ahem, are you exploring new boundaries of purist OOP, and at the
same
time considering globals???
Let alone, that from a practical point of view, it would obstruct
multiple simultaneous instances.
and you are absolutely 101 % correct.
I think the key issue is:
No matter how convoluted you
I think the key issue is:
No matter how convoluted you make the structure, to avoid having a
getter method in the qtObject, you will either wrap the
slider-code
inside the main qtObject, or accept passing data from one object and
to another at some point.
yes. how indeed do you have
I would like to join in on this thread; in particular I would like to know
if anyone has thought about using the patterns approach in Director. The
intent of contributors to this thread seems consistent with the work of
Gamma, Helm, Johnson, and Vlissides (affectionally known as the Gang of
on 14/8/01 2:30 am, Al Hospers wrote:
1 - instantiation: setup initial property values
2 - monitorPlaybackStatus: is it playing, stopped, paused
3 - getCurrentPosition: what is the current position of the movie
4 - play: start playing at the current location
5 - stop: stop playback
with other objects? I believe you mentioned a slider in your previous post?
ck
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
Behalf Of Al Hospers
Sent: August 13, 2001 6:30 PM
To: [EMAIL PROTECTED]
Subject: RE: lingo-l OOP and ancestor access
this is a good idea
Christian Wach [EMAIL PROTECTED] wrote
Subject: Re: lingo-l OOP and ancestor access
on 14/8/01 2:30 am, Al Hospers wrote:
1 - instantiation: setup initial property values
2 - monitorPlaybackStatus: is it playing, stopped, paused
3 - getCurrentPosition: what is the current
Well I'm coming to the end of an absolutley brutal day so I can not vouch
for the clarity of any comments I make here
Item 1 - instantiation would probably (and most importantly) cache values
such as movie duration, so we might need to have a special handler which
does this more than once
At 23:28 +0200 2001_08_14, Brennan Young wrote:
I just read the article.
A very interesting discussion, if this holds water, then it
definitely rocks my OOP-boat.
It appears, that his dogma could also be described as never pass
data between objects.
I suspect that he is somehow beating around
Al Hospers wrote
so how do you have a slider behavior communicate with a
QTPlaybackObject? or do you? the slider needs to know the current
location of the movie. should it get the information itself from the
movie, or should it retrieve it from the object - which is always
monitoring the
Getter and Setter
methods are evil or something to that effect. Essentially
it says that if
you have a method that simply returns any private data
(such as properties
in a lingo object) that this is essentially just a cheat
for making private
data public. Wow! Pretty strong statement.
snip
1) have the object publish the data publicly to a global variable?
this will work fine, tho I just try to keep globals down.
snip
This one works just fine if speed is the issue here. Kerry had mentioned a
project he tackled a while back which illustrates this point very nicely.
He had a
I've come from a smalltalk background (not that it is useful for
anything anymore) which has to be one of the most anal OOP environments
there is...
in Al's example:
you have a behavior that moves a slider around that needs the current
position data
...Maybe your approach is still
in Al's example:
you have a behavior that moves a slider around that needs
the current
position data
...Maybe your approach is still too procedural. Can the
slider not
just tell the object its new position once it gets moved and have
the
object calculate the new movie position from
interesting thread. I haven't really thought about some of these
baseline issues in a while.
I think OOP is only just coming of age - its only now that us
normal programmers start hashing out the issues. This is a
particularly interesting thread because Director isn't locked into
Al Hospers wrote:
now how to address the slides moving as the movie plays. one method
may be to register the appropriate slider method sprite with the
object. then the object would send the current movie position to the
slider at regular intervals. the slider would perform the calculations
I may be missing something, but (as the subject line implies) how
about making the monitoring object an ancestor of the slider object?
If the slider 'inherits' all the methods and properties of
the monitoring
object, then surely there's no need for the global... and no
need to do
the
Brennan Young wrote:
Glad you brought this up again, Colin.
I'm sure others are not so happy;)
1) It's more difficult to program (but so was switching to OOP
for me a few
years back and now I never program without it).
Perhaps, yes. I've found it easier than I expected to take this
At 11:56 13/08/2001, Colin Kettenacker wrote:
It appears that Al has started an interesting thread on the topic.
Indeed, and speaking as one who's OOP light bulb is not just popping on
as I've seen mentioned in several places (it seems to be on a dimmer
switch) , I always read these threads
this is a good idea. let's talk thru an analysis of a real-life useful
OOP module. that should get this thread hoppin, right. I'll start it
up. let's take the example that I mentioned before, the QT/digital
movie object? let's not write any code yet, let's just do a sketch.
here are the various
Colin Kettenacker wrote
However a more interesting debate is the need for accessor (getter)
methods at all.
Some time back, on one of the director mailing lists, Brennan Young (I
think) had found an article on OOP that he posted to that list. I will see
if I can find the URL again... Here
66 matches
Mail list logo
