BeOS, running out of time
tc...@cix.compulink.co.uk
desktop OS is running out of time. One of the reasons for moving to Be
from Windows was the underlining Unix environment (though single user) and
to a smaller extend (for me) the easy API. Oh yes and great SMP, my twin
Tyan Tiger100 (PII 450) is now sitting at work just crunching SETI blocks
(now at 500). Which I have to reboot every 2 weeks to overcome a memory
leak somewhere (ver 4.5.2).
But being a admin user and not a C++ developer I think that OS X will
eventually win my vote. With BSD underneath and access to classic apps
and newer apps being developed for Aqua, I think that BeOS will stay as a
minority OS and thus limited apps.
The chances of Adobe cross developing to BeOS are very very small. But OS
X has a brighter future for main-line app development. I do a lot of bash
shell stuff and perl for various projects, with OS X I should be able to
do the same. I am a CLI junkie but like GUIs, given the option I would
write a script for CLI than write an app for a GUI. And that's the reason
I like BeOS. MAC OS before X is ok but there is no CLI environment and no
Unix. Now there will be
Linux was just too much hassle, BeOS gave me an easy, maintenance free
Unix like environment without the hassle of keeping Linux going. Now
MACOS X should give me that as well.
It is a real shame because I do like BeOS its just the apps and slow
development (BONE, OpenGl, QuakeIII arena) that will persuade me to spend
my cash on a new MAC instead of an Intel box for BeOS.
I will keep my shares though (with BeIA in mine). I might sell a few to
get a new 466MHz iBook.
[-----------------------]
Ameol via SoftWindows98
Jerry Cornelius
> development (BONE, OpenGl, QuakeIII arena) that will persuade me to spend
> my cash on a new MAC instead of an Intel box for BeOS.
Have fun. See you around.
Personally, I'll never buy anything from Apple especially since the return
of Jobs.
"1984" We are not Big Brother. Say, is that a trash can on a desktop?
Buddy, we're gonna sue you out of business.
Earl Colby Pottinger
> With the imminent arrival of MACOS X (BSD Unix) I think that Be as a
> desktop OS is running out of time. One of the reasons for moving to Be
> from Windows was the underlining Unix environment (though single user) and
> to a smaller extend (for me) the easy API. Oh yes and great SMP, my twin
> Tyan Tiger100 (PII 450) is now sitting at work just crunching SETI blocks
> (now at 500). Which I have to reboot every 2 weeks to overcome a memory
> leak somewhere (ver 4.5.2).
First, BeOS was never Unix underneath! (Minor point). It's APIs and UI
however
has always been easyier to use than Windows, and I think more powerful to
the casual user than MacOS.
> But being a admin user and not a C++ developer I think that OS X will
> eventually win my vote. With BSD underneath and access to classic apps
> and newer apps being developed for Aqua, I think that BeOS will stay as a
> minority OS and thus limited apps.
First, classic Unix programs are not Mac programs. I think the average Mac
user will not want the classic unix programs. This ofcourse does not prevent
thier use in Unix shops! Second, no matter what the kernel writting good Mac
programs to the "Bible's" specs is hard work. Expect to see lots of ports
of programs already available for the Mac. However, new and interesting
programs are still going to be far apart.
> The chances of Adobe cross developing to BeOS are very very small. But OS
> X has a brighter future for main-line app development. I do a lot of bash
> shell stuff and perl for various projects, with OS X I should be able to
> do the same. I am a CLI junkie but like GUIs, given the option I would
> write a script for CLI than write an app for a GUI. And that's the reason
> I like BeOS. MAC OS before X is ok but there is no CLI environment and no
> Unix. Now there will be
But BeOS and other OSs have Bash and Perl! That is the advantage to going
to Mac? The question is why drop my present OS to go to another OS? PS.
Is MACOS X for Intel confirmed or are you going to buy new hardware?
> Linux was just too much hassle, BeOS gave me an easy, maintenance free
> Unix like environment without the hassle of keeping Linux going. Now
> MACOS X should give me that as well.
But if you are already setup in BeOS why move?
> It is a real shame because I do like BeOS its just the apps and slow
> development (BONE, OpenGl, QuakeIII arena) that will persuade me to spend
> my cash on a new MAC instead of an Intel box for BeOS.
AH! A good reason at last! And what do you need to stay?
> I will keep my shares though (with BeIA in mine). I might sell a few to
> get a new 466MHz iBook.
> [-----------------------]
> Ameol via SoftWindows98
As long as it's not your life investments. If BeIA does well those stock
will rocket!
Earl Colby Pottinger
--
Hydrogen Peroxide Rockets, BePrint, BePrinter, RAMDISK, Cabin Raising,
Camping, BoatBuilding, Girlfriend. What happened to the time?
Marco Nelissen
David Siefert
> With the imminent arrival of MACOS X (BSD Unix) I think that Be as a
> desktop OS is running out of time. One of the reasons for moving to Be
> from Windows was the underlining Unix environment (though single user) and
> to a smaller extend (for me) the easy API. Oh yes and great SMP, my twin
> Tyan Tiger100 (PII 450) is now sitting at work just crunching SETI blocks
> (now at 500). Which I have to reboot every 2 weeks to overcome a memory
> leak somewhere (ver 4.5.2).
Keep in mind BeOS was the first to implement all this stuff like fast
bootups, immediate hardware detection, heavy multithreading, network
enhancements, etc. Windows and Mac OS is just finally getting around to it.
BeOS was made in 1990, R3 was released around 1997 though I think. Who do
you think will be ahead of OS technology in the future? It sure as hell aint
gonna be MS or Apple.
> But being a admin user and not a C++ developer I think that OS X will
> eventually win my vote. With BSD underneath and access to classic apps
> and newer apps being developed for Aqua, I think that BeOS will stay as a
> minority OS and thus limited apps.
New BONE will kick serious ass. From what I hear, it will have the same
performance, if not better, than BSD. Too bad software companies dont
program in BeOS. They could probably crank out products a lot faster,
thanks to the Be API's.
> The chances of Adobe cross developing to BeOS are very very small.
True, but in the future when BeOS is kicking more ass, im sure Adobe will
finally realize it and start porting.
> But OS
> X has a brighter future for main-line app development. I do a lot of bash
> shell stuff and perl for various projects, with OS X I should be able to
> do the same.
BeOS has the bash shell, what is the problem here?
> I am a CLI junkie but like GUIs, given the option I would
> write a script for CLI than write an app for a GUI. And that's the reason
> I like BeOS. MAC OS before X is ok but there is no CLI environment and no
> Unix. Now there will be
When was MacOS ever good? I dont have a lot of experience ever using a Mac,
but from what Ive read from Scot Hacker, he mentioned MacOS crashes a lot.
What is funny is that the Apple MacOS demo showed an application trying to
crash the entire system through writing to spots in memory randomly. This
was obviously a fake. Mr. Jobs knows how to show off to idiots.
> Linux was just too much hassle, BeOS gave me an easy, maintenance free
> Unix like environment without the hassle of keeping Linux going. Now
> MACOS X should give me that as well.
BeOS adopted an extremely simple install process first (boot, partition,
format, copy, boot, use).
> It is a real shame because I do like BeOS its just the apps and slow
> development (BONE, OpenGl, QuakeIII arena) that will persuade me to spend
> my cash on a new MAC instead of an Intel box for BeOS.
MAC's are expensive, and Apple has made them so you cant really upgrade them
that much. So you end up buying an entirely new mac to get more features.
Expensive.....
> I will keep my shares though (with BeIA in mine). I might sell a few to
> get a new 466MHz iBook.
Good, at least your still supporting the company. :-)
-Dave
n9
David Siefert <dsie...@codebe.com> wrote:
snip
>
> Keep in mind BeOS was the first to implement all this stuff like fast
> bootups, immediate hardware detection, heavy multithreading, network
> enhancements, etc.
so what?
> When was MacOS ever good? I dont have a lot of experience ever using a Mac,
> but from what Ive read from Scot Hacker, he mentioned MacOS crashes a lot.
R5.03 Pro crashes way, way, way more than my G3 PB. Actually I'm kinda
astonished at how much I get dumped into the debugger, or it just locks
and I have to turn off power. Now whether that's the MediaPlayer
(happens a lot when running movies) or something else I don't know.
I've actually thought of going back to 4.5. Also networking seemed to
be more stable in R4.5, though I can't really quantify that.
n9
Kenneth C. Dyke
>
>Keep in mind BeOS was the first to implement all this stuff like fast
>bootups, immediate hardware detection, heavy multithreading, network
>enhancements, etc.
Aside perhaps from the networking, I'd say the Amiga probably had BeOS
beat on the first three before BeOS development ever even got started.
The heavy multithreading might be argued either way, but overall I'd
argue that AmigaOS has things partitioned into multiple tasks (threads
are sortof a pointless concept on an OS with only a single address
space) far more than BeOS does.
>Windows and Mac OS is just finally getting around to it.
>BeOS was made in 1990, R3 was released around 1997 though I think.
Who do
>you think will be ahead of OS technology in the future? It sure as
hell aint
>gonna be MS or Apple.
That depends on what technology you're looking for. In terms of
generalized core OS stuff goes, not a lot has really changed in the
past 20 years or so, except that PC-level machines have caught up to
where more powerful systems were 20 years ago.
However, I'd stack the graphics subsystem in OS X up against anything
out there. Just about every OS in use right now (except perhaps for
NeXTSTEP/OpenStep if you want to count those) is still using a circa
80's rendering model. DPS was at least 90's. Quartz will probably be
ahead of the curve for a while. Certainly as hardware gets faster
performance will get better. I'd say it's better to design something
that'll be really fast tomorrow (that hardware can grow into), rather
than only sticking with the same rendering model that all of the
current Windows hardware is optimized for.
>New BONE will kick serious ass. From what I hear, it will have the
>same performance, if not better, than BSD. Too bad software companies
>dont program in BeOS. They could probably crank out products a lot
>faster, thanks to the Be API's.
Dunno, I'm probably biased but I'd bet most folks could get stuff done
with Cocoa/Quartz faster than they could with Be's Application kits.
People tend to balk a lot because of Objective C, which is really a
shame. I'm still amazed at the level of pain C++ programmers are
willing to put themselves through to try to get close to what other
languages offer out of the box.
>> But OS
>> X has a brighter future for main-line app development. I do a lot
of bash
>> shell stuff and perl for various projects, with OS X I should be
able to
>> do the same.
>
>BeOS has the bash shell, what is the problem here?
But bash doesn't say anything about the rest of the system *at all*.
Hell, the Amiga had csh ports, but I'm not sure I'd say that this by
itself made it easier to Unix-y shell stuff. Certainly having posix
support within BeOS takes things a lot farther, although there was a
lot of effort (by third parties) to provide similar functionality to
AmigaOS. Personally I'd rather have the real thing.
>What is funny is that the Apple MacOS demo showed an application
>trying to crash the entire system through writing to spots in memory
>randomly. This was obviously a fake. Mr. Jobs knows how to show off
>to idiots.
Why would that have to be a fake test?
>BeOS adopted an extremely simple install process first (boot,
>partition, format, copy, boot, use).
No more or less complex than the OS X install procedure, except that OS
X can run off of an existing HFS+ partition. I guess perhaps it
requires one extra reboot to get a few things configured the first
time. It's certainly better than Windows which always seems to take
about 7 restarts to get all of my PC's hardware detected. Ugh.
-Ken
--
Kenneth Dyke, k...@jumpgate.com (personal), kd...@apple.com (work)
Sr. Mad Scientist, MacOS X OpenGL Group, Apple Computer, Inc.
C++: The power, elegance and simplicity of a hand grenade.
JFW
C. Dyke) wrote:
>On 09/21/00, "David Siefert" wrote:
>>
>>Keep in mind BeOS was the first to implement all this stuff like fast
>>bootups, immediate hardware detection, heavy multithreading, network
>>enhancements, etc.
>
>Aside perhaps from the networking, I'd say the Amiga probably had BeOS
>beat on the first three before BeOS development ever even got started.
>The heavy multithreading might be argued either way, but overall I'd
>argue that AmigaOS has things partitioned into multiple tasks (threads
>are sortof a pointless concept on an OS with only a single address
>space) far more than BeOS does.
Actually, OS9 had Amiga beat on multithreading applying your argument
(and in Tandy Coco's WAS a consumer-used OS). Amiga and fast bootup
has always been an issue for debate. In terms of immediate hardware
detection, well, when did NuBus slots appear?
>>New BONE will kick serious ass. From what I hear, it will have the
>>same performance, if not better, than BSD. Too bad software companies
>>dont program in BeOS. They could probably crank out products a lot
>>faster, thanks to the Be API's.
>
>Dunno, I'm probably biased but I'd bet most folks could get stuff done
>with Cocoa/Quartz faster than they could with Be's Application kits.
I'm certain of it. Witness the discussions of late regarding the
horrific implementations of ordered lists, etc. and other Interface
Kit widgets.
>People tend to balk a lot because of Objective C, which is really a
>shame. I'm still amazed at the level of pain C++ programmers are
>willing to put themselves through to try to get close to what other
>languages offer out of the box.
Doesn't that cross get heavy? <grin> You know I agree with you that
it's superior in nearly every way to C++, but at some point...
>>BeOS adopted an extremely simple install process first (boot,
>>partition, format, copy, boot, use).
>
>No more or less complex than the OS X install procedure, except that OS
>X can run off of an existing HFS+ partition. I guess perhaps it
>requires one extra reboot to get a few things configured the first
>time. It's certainly better than Windows which always seems to take
>about 7 restarts to get all of my PC's hardware detected. Ugh.
OTOH, to be fair, Windows actually makes an effort to detect
third-party hardware. <grin> My MOTU PCI-324 and OrangeMicro USCSI
xface (both reasonably well-known products) aren't seen at all by OS X
Public Beta. You must admit that in publically-available betas,
Microsoft does a FAR better job at including drivers for third-party
hw. Hell, OSXPB doesn't even include 3dfx support. <grin>
JFW
P.S. Ken, didn't feel comfortable responding to your csma post till I
had a legit OSXPB in hand. Also, thanks for the reminder on PES.
Ken Curtright
>
> R5.03 Pro crashes way, way, way more than my G3 PB. Actually I'm kinda
> astonished at how much I get dumped into the debugger, or it just
> locks
> and I have to turn off power. Now whether that's the MediaPlayer
> (happens a lot when running movies) or something else I don't know.
> I've actually thought of going back to 4.5. Also networking seemed to
> be more stable in R4.5, though I can't really quantify that.
>
> n9
You're full of shit!!!
As someone who just bought my first PC after owning Macs for 7 years, I
know, without a doubt, that all PC operating systems I have tried are
more stable than the MacOS. This includes Windows 2000, Linux, and the
BeOS. In the month I have been running BeOS pro 5.0.3 on my machine it
has been rock solid. I've never had a system crash under BeOS 5.0.3 for
Intel. This is very different than under MacOS where I would often have
multiple system crashes in the same day.
For what it's worth, I have crased Windows 2000 one time. I tried to
force quite a game that was misbehaving and brought down the whole
system.
I will say that BeOS on PPC wasn't as stable for me as BeOS on Intel is,
so if your only experience with BeOS is on PPC then perhaps my statement
about you being full of shit is a bit harsh. You're then merely ignorant
and shouldn't be making statements about things you don't have
experience with!
Ken.
--------------------------------------------------
The more I use Windows, the better I like the BeOS.
n9
<ken...@nospam.pacbell.net> wrote:
> n9 wrote:
> >
> > R5.03 Pro crashes way, way, way more than my G3 PB. Actually I'm kinda
> > astonished at how much I get dumped into the debugger, or it just
> > locks
> > and I have to turn off power. Now whether that's the MediaPlayer
> > (happens a lot when running movies) or something else I don't know.
> > I've actually thought of going back to 4.5. Also networking seemed to
> > be more stable in R4.5, though I can't really quantify that.
> >
> > n9
>
>
> You're full of shit!!!
snip
uuuuhhhh... Ok.
Sorry, thought my Be machine was crashing; obviously it's not.
Again, sorry, won't let it happen again.
n9
Kenneth C. Dyke
>On Fri, 22 Sep 2000 06:30:53 GMT, k...@babylon5.jumpgate.com (Kenneth
>C. Dyke) wrote:
>
>>>
>>>Keep in mind BeOS was the first to implement all this stuff like
fast
>>>bootups, immediate hardware detection, heavy multithreading, network
>>>enhancements, etc.
>>
>>Aside perhaps from the networking, I'd say the Amiga probably had
BeOS
>>beat on the first three before BeOS development ever even got
started.
>>The heavy multithreading might be argued either way, but overall I'd
>>argue that AmigaOS has things partitioned into multiple tasks
(threads
>>are sortof a pointless concept on an OS with only a single address
>>space) far more than BeOS does.
>
>(and in Tandy Coco's WAS a consumer-used OS). Amiga and fast bootup
>has always been an issue for debate. In terms of immediate hardware
>detection, well, when did NuBus slots appear?
Oh yeah, I'd forgotten about OS/9. My bad. Just another useful data
point I guess. ;)
>>People tend to balk a lot because of Objective C, which is really a
>>shame. I'm still amazed at the level of pain C++ programmers are
>>willing to put themselves through to try to get close to what other
>>languages offer out of the box.
>
>Doesn't that cross get heavy? <grin> You know I agree with you that
>it's superior in nearly every way to C++, but at some point...
What, we all decide to give in and just go with what everyone else uses
even if it sucks? Personally I don't care if I'm the last person on
the planet to still be using Objective C. Untill something better
comes along (or SmallTalk really starts to take off after all these
years), I'll stick with what works. ;) I think it's interesting that
languages such as Objective C and SmallTalk are still being used today
*at all*. Granted, they may be niche players at the moment, but if
they solve problems, that's the important thing.
>OTOH, to be fair, Windows actually makes an effort to detect
>third-party hardware. <grin> My MOTU PCI-324 and OrangeMicro USCSI
>xface (both reasonably well-known products) aren't seen at all by OS X
>Public Beta. You must admit that in publically-available betas,
>Microsoft does a FAR better job at including drivers for third-party
>hw. Hell, OSXPB doesn't even include 3dfx support. <grin>
Well, I'm sure IOKit sees the hardware, it's just not finidng any
drivers to claim it. It's just not like Windows where it's going to
prompt the user for every new piece of hardware it sees that it doesn't
have a driver for. In fact, I don't know of any OS other than Windows
that actually does that sort of thing.
On the other hand, most other operating systems don't throw a fit when
a card gets moved from one slot to another, prompting you to re-install
a driver for it. ;)
Spendocrat
>
> Dunno, I'm probably biased but I'd bet most folks could get stuff done
> with Cocoa/Quartz faster than they could with Be's Application kits.
> People tend to balk a lot because of Objective C, which is really a
> shame. I'm still amazed at the level of pain C++ programmers are
> willing to put themselves through to try to get close to what other
> languages offer out of the box.
As someone semi-new to programming, I'm wondering what you mean here,
and why you feel Objective C is superior to C++. Also, when you refer
to C++, are you talking about 1997/8 ISO C++ or pre-ISO?
I'm not very experienced with matters of C++, but please be as techincal
as you like.
Thanks
R. Edward McCain
C. Dyke) wrote:
>What, we all decide to give in and just go with what everyone else uses
>even if it sucks? Personally I don't care if I'm the last person on
>the planet to still be using Objective C. Untill something better
>comes along (or SmallTalk really starts to take off after all these
>years), I'll stick with what works. ;)
Change must come from the inside, Grasshopper.
--
R. Edward McCain
email address upon request
ICQ: 599146
Kenneth C. Dyke
>"Kenneth C. Dyke" wrote:
>>
>> Dunno, I'm probably biased but I'd bet most folks could get stuff
done
>> with Cocoa/Quartz faster than they could with Be's Application kits.
>> People tend to balk a lot because of Objective C, which is really a
>> shame. I'm still amazed at the level of pain C++ programmers are
>> willing to put themselves through to try to get close to what other
>> languages offer out of the box.
>
>and why you feel Objective C is superior to C++. Also, when you refer
>to C++, are you talking about 1997/8 ISO C++ or pre-ISO?
>
>I'm not very experienced with matters of C++, but please be as
techincal
>as you like.
Well, there are probably lots of reasons, but the single biggest one is
probably the way methods are dispatched in the two languages. I
believe that most of my gripes with C++ can be applied to pretty much
every version of it that has ever existed.
Warning: This is a long post, but he asked, so here goes.
The dispatching in C++ is effectively done by code generated by the
compiler. All of the decisions are mode in code generated at the call
site of the member function.
In order for this to work, the C++ compiler must see declarations of
every single method that a class has. It will not allow you to call
member functions that aren't in the class declaration. One of the
primary reasons for this is that the designers of C++ would probably
argue that doing so would constitute a design defect in your program
(which I'll argue below is not necessarily true). The other reason is
that without having seen the delaration, the compiler wouldn't be able
to figure out which offset into the C++ vtable to use in the first
place, since the offset will be hardcoded when the program is compiled.
Incidentially, this hardcoded offset is why C++ breaks so badly when
virtual methods are added or removed.
In contrast to C++, Objective C's method dispatching is not done by the
compiler. It is done by a helper function at runtime that dynamically
looks up the code pointer at run time, based on the class of the object
and the name of the method being invoked. While this does generate
additional overhead, it is not as expensive as a full string compare
operation. Unique hashes are generated for each method name known by
the runtime, and the hashes are used with a caching mechanism to reduce
the method lookup as much as possible. These unique hashes can also
be passed around at runtime, and used in places other than in method
calls (see below for an example).
Also unlike C++, Objective C has the concept of an anonymous object
type, namely "id". Methods invoked using that type are not checked by
the compiler at all, and the compiler simply spits out the code
necessary to invoke the method you wanted.
As a simple example of where you'd use the anonymous method
dispatching, consider the NSControl class in OpenStep. NSControls have
the concept of a "target" and and "action" to be performed on that
target when the control is maniputaled by the user. A simple subclass
of NSControl is NSButton, which simply makes a method call to a target
object whenever the button is clicked.
The way this is implemented is very simple. NSControl essentially
declares two pieces of data as part of it's instance data:
id target
SEL selector;
(SEL is the type used for the unique method ids mentioned above).
Whenever the control is activated, the following code is used to invoke
the method:
[target performSelector:selector withObject:self];
Action methods in OpenStep by convention always accept a single
parameter, a pointer to the object that invoked the action. The way I
would use this in code (ignoring such tools as Interface Builder that
do all of this for you) would be something like this (greatly
simplified):
NSButton *myButton = [NSButton new];
// Do some work to place the button in an NSView, etc...
...
[myButton setTarget:myDocument];
[myButten setAction:@selector(deleteItem:)];
...
Later, in my fictional Document class, I'd have a deleteItem: method
that looked something like this...
- (void)deleteItem:(id)sender
{
// Do whatever work is necessary to delete the currently
// selected item (if anything).
if(selectedObject) {
[items removeObject:selectedObject];
}
}
In some ways this is similar to how BControls are implemented, except
that they require the use of BMessages to pass actions from the
controls to the targets. This then also requires that programmers
create a bunch of message codes that then have to manually dispatched
(usually in a big switch() statement) in order to get the final code
that they want called.
This is all fine and good and you can argue back and forth about which
way is better, but the *real* power of the dynamic dispatching comes
into play when you start looking at what happens when you try to call a
method that an object *doesn't* actually implement.
If you do indeed attempt to call an unimplemented method, the method
dispatcher function realizes that it can't find the method you wanted
defined anywhere in the inheritance chain. In this case, it builds an
NSInvocation object to represent the call you tried to make (along with
all of it's arguments) and calls the forwardInvocation: method on your
object. The default implementation of this in NSObject is to raise an
exception. However, other more useful things can be done.
Instead of raising an exception, NSProxy will take the method call and
dispatch it via an IPC mechanism to objects running in a different
address space (or even on a differenc computer). In this way, you can
do completely transparent communication with distant objects as if they
existed inside your program. It can do this without the programmer
having to write special custom proxy objects or without having to use
some form of IDL.
My favorite example of using NSInvocation though is the Undo mechanism
in Apple's Foundation Kit. What NSUndoManager does is "record" the
methods used that would be needed to "undo" any particular operation
you're about to do on an object.
For example, if you were implementing a drawing program and had a
method for setting the color of an object in your document class, it
might look something like this:
- (void)setColor:(NSColor *)newColor
{
[[undoManager prepareWithInvocationTarget:selectedObject]
setColor:[selectedObject color]];
[selectedObject setColor:newColor];
}
What the prepareWithInvocationTarget: method in NSUndoManager does is
return an object that is going to rember the target object passed into
the prepareWithInvocationTarget: method, and the method call that it is
invoked on it. In this case, it records a call to setColor: that is
passed an NSColor object that represents the current color of the
currently selected object before we actually change it to the new
color. This method is recorded simply be saving a copy of the
NSInvocation object that is generated by the runtime when we called the
setColor: method on the object returned from the
prepareWithInvocationTarget: call.
We then actually change the color in the selected object to the new
color and go on about our business.
Later, if we wish to undo that operation, we simply call the "undo"
method on our undoManager. It then goes off and processes the last
"done" operation. It finds the object created before, which then takes
that NSInvocation object and "invokes" it, which causes the original
method call that was recorded to be called with the object who's color
was changed.
This is the sort of power (among a bunch of other things) that I can
simply take for granted when using Objective C. Granted, some of the
stuff I get to take advantage of is because other programmers (of
Foundation/AppKit/etc.) have done the work of encapsulating a bunch of
stuff for me, but it's still the language that enables this sort of
thing to be done *easily*.
Implementing undo/redo support in C++ seems to always require that you
implement custom "command" or "action" classes to represent every kind
of action that can be done in your application. It seems silly to me
to write a class who's only purpose in life is to do little more than
make a method call, just so that all of those action objects can have
some common interface that the C++ compiler can deal with.
There are plenty of other neat things Objective C offers, but the
method dispatching goes right to the core of the issues for me.
Spendocrat
Spendocrat
"Kenneth C. Dyke" wrote:
>
<snip of excellent post>