Which is better? OS 4 or Morph OS . . .

[Karlos]

I was more thinking of new systems to usurp the old ones. Things like datatypes, in their present guise are fundametally flawed IMHO. But that is another discussion entirely and we are off topic enough already :-)

[Karlos]

@itix

To begin, I said interfaces share several important facets with C++ classes, I didn't say they were equivalent C++ classes. Therefore, inheritence is not something that is not implicit in the interface design as ultimately C is not an OO language. However, that doesn't mean it is not supported at all...

How inheritance would work? For example if you subclass root class and ad your own methods -- how root class is supposed to handle them?

Remember, a parent class never does have any knowledge of any of any of its childrens' unique methods or properties. Consider an actual C++ class heirarchy. If your parent class is HouseholdPet, and you have sublcasses of GoldFish, Cat, Dog, Budgie, etc, *only* the interface defined by HouseholdPet is common to all. Each implements the HouseholdPet interface and adds some unique methodst too. Dog might add a method chasePostman() to the existing set of methods it inherited from HouseholdPet.

You cant expect to call a Dog specific method such as chasePostman() via an "HouseholdPet* pet" (unless you use RTTI and do a dynamic_castpet and check it was valid) as your particluar pet might be an instance of GoldFish.

-edit-

Mind you, that would be something to see :roflmao:

-/edit-

In this regard, interfaces are no different to classes. I can't realistically call a method of a sub interface via a handle to the parent that the parent does not already advertise.

The second issue is polymorphism. Customising methods of the parent interface to suit the specific child so that different instances of an interface might perform the same method call differently. This is perfectly doable. Remember, the methods are really just embedded function pointers within the interface structure and can be changed. If I cloned an instance of IKarlDevice, I can provide my own function to handle the Initialize() method specifically for that one instance (similar to SetFunction() on a library).

On the other hand you need a class pointer to call super class. On the other hand you must access your local object data somehow

How do I call the 'parent' implementation's method within my method? Well, provided I just don't blitely throw the old pointer away, I can use it to call the original IKarlDevice's implementation too, if I need to. OK, this is not quite as nice as being able to do a java esque "super()" call but it is achievable without that much fuss. I dont see libraries having it any easier.

Furthermore, since interfaces are just structures, provided I give them unique names, I can create any number of cast compatible clones of struct IKarlDevice, eg struct IKarlKeyobard, struct IKarlMouse (adding any unique stuff only at the end of the structure, again like library bases do). Each of these can implemented by totally different libraries. This allows me, if I need to, to handle instances of totally different implementations (as opposed to just modifying a single instances function pointer) of an interface without having to exactly know what they are.

If you look into OS4 documentation you will find out interface has
a) function table at positive offset
b) data at negative offset

AmigaOS 3 library base has
a) function table at negative offset
b) data at positive offset

That's the implementation difference between them. How they can be used by the developer and they can assist the developer in achieving his goals are more important.

I stand by the observation that interfaces simpify the creation of this type of construct compared to achieving the same thing with 3.x libraries (or even boopsi classes).

If you prefer doing this type of thing with 3.x style library bases and the 3.x source compatible ways of calling their code, that is entirely up to you. I personally find it much less cumbersome to accomplish this type of thing with the interface syntax.

[Karlos]

redfox wrote:
@Edpon

Which is better? OS 4 or Morph OS . . .

By the discussion so far, I would say the experts can't decide :lol:

redfox

I have to apoligise to the thread author, really. This discussion is nothing really to do with the question that was asked :lol:

Which OS is better? That depends on your selection criteria. Due to the nasty politics that led us to where we are now, many people don't have the choice, since each OS is somewhat tied to a hardware choice too.

Only the classic ppc systems, at this time are capable of running both. That said, the classic systems are (in performance terms) eclipsed by the A1, Peg etc., on which the respective OS's really show their true potential.

[Karlos]

@Acill

I for one have used MOS since the PEgasos came out and like it much better then OS4

Have you used OS4 too, or is that a subjective opinion on what you think OS4 is like to use?

It would be interesting to see what someone like Wilse, who has both platforms to hand would have to say.

I haven't downloaded MOS for BPPC yet, but it's on my to do list. I could then give a more educated comparison, at this time I don't know enough about MOS to comment.

[Karlos]

:roflmao:

@Doobrey

Interesting argument. However, the unshaven soapdodger genus of programmer belongs to the era of procedural programming. Those of us that subscribe to the more recent OO paradigm prefer cleanliness ;-)

Whilst I'm not going to comment on the "better programmer" thing, I don't originally come from an AmigaOS coding background and I think it is perfectly fair to say that Harry's knowledge of AmigaOS specific coding is more extensive than mine.

[Karlos]

Darth_X wrote:
If OS4 and MorphOS were equal, then what would be a deciding factor? The community behind each platform? Industry recognition?

If they were equal, would there really be a deciding factor? Equality implies they'd run the same software on the same range of hardware. It would be entirely down to personal taste.

[Karlos]

@Edpon

Well, Piru and I were engaged in a different discussion really that was an offshoot of an implementation difference between the two.

You can run both on one machine (not concurrently), a classic machine equipped with a PPC card and an RTG card can run versions of both OS's. I see no reason why you cant have multiple bootable partitions. I myself have OS3.1, 3.5, 3.9 and 4.0 on my A1200T. Adding one more for MOS shouldn't exactly be rocket science.

However, OS4 for BPPC/CSPPC is currently not available outside the betatester group. Conversely, MOS for CSPPC/BPPC is available for download.

I don't expect to see OS4 running on Peg or MOS running on A1 anytime soon (a lot of nasty politics, in fighting etc has gotten us into this situation), which is a shame since these machines are a lot more powerful than their classic counterparts.

Hardware support, for both systems, is understandably a lot narrower than it is for PC. Ultimately this is dominated by driver availability. Some hardware vendors (eg nVidia) take a proprietry view of this issue, so don't expect to see support for the HW anytime soon.

If you are undecided your best bet is to try to attend any local shows etc where you might have the opportunity to try them both in order to make up your mind.

[Karlos]

boing wrote:

Maybe the better question is this:

Is there a way to run OS4 and MorphOS on the same box?  By hook or by crook.  I don't give a darn about bending the rules.

If you own a classic PPC based system and you have access to OS4, yes. If you own either an A1 or Peg, then for now you are limited to either/or.

[Karlos]

@AmigaMance

OS4 has a 68K interpreter built in. There is also a JIT implementation available for it called Petunia but this is currently restricted to betatesters. I am a bit behind the current release as I have had no time to spend on my system, but at the last test it was fast enough. Depending on the code at hand, my 240MHz 603 could interpretively emulate many 68K applications at a speed comparable to my real 68040 @ 25MHz, which was pleasently surprising. The JIT, suffice to say, was a lot faster.

-edit-

Clarification to avoid any misunderstanding about the general availablity of petunia.

[Karlos]

@itix

I really think we should open another thread for this, but...

itix wrote:

I'm not sure: would every class have its own interface structure or would subclasses inherit its parent interface structure and extend it. If so, how?

For simple extensions, where you only need to change a method or two, cloning an instance of the parent and changing the function pointers for the methods you need would be sufficient.

When you need an extended structure, every class having its own interface structure is likely simplest as there simply is no way in C to extend a structure. Otherwise you do what you would to in a library and have the parent structure as the first member and remember which cast you are using. This is a limitation of C itself, not interfaces or library bases.

When you need an extended structure, you have

In BOOPSI you can. It is just ignored by super class. Either way interface (as in struct Interface) cant replace intuition objects at all.

Of course it can't replace BOOPSI directly (that is making existing boopsi fit interfaces and remain compatible), or at least without a lot of effort.

It can, however easily replace boopsi as a fondation. I've already experimented a little in this area, a simple inteface definition with event handler / render methods implemented as one of three simple objects (this was a direct adaptation of my C++ framwork's unfinished guilib idea).

A future GUI framework not based on boopsi but upon interfaces is entirely possible, it just would have no backwards compatibiliy with boopsi at any level.

In my opinion 3.x style is just fine. I've used it so many years already :-O

Entirely your choice. Have you tried any of the types of OO construct design discussed here using only 3.x style and library bases? I have and it is quite frustrating compared to the interface approach.

[Karlos]

Piru wrote:
@Karlos

There is also a JIT implementation available for it called Petunia.

It is? Damn, I must have gotten some wrong information then. My source claimed it wasn't available outside of betatesting (that is, that it wouldn't be available for mere mortals).

Sorry, I wasn't completely clear. Hey, I've been virtually dying of a cold these last few days you know. It is avaliable in that it exists, but is presently only available to betatesters. I have tested earlier versions on my BPPC but my betatesting has been very lacking of late due to other commitments :-( I can only assume, however that it will be present in the final release. I hope so anyway :-)

[Karlos]

itix wrote:

But would it give a significant performance boost compared to BOOPSI? Calling a method in BOOPSI is not very expensive after all. There is some extra overhead in dispatchers but I think current BOOPSI is quite good.

Horses for courses really. An interface call (inderect call from a function pointer) is unarguably much faster than a Boopsi call (dispatcher shennanigas), but when you consider a typical GUI is mostly waiting for stuff to happen I would say not. I do find interfaces cleaner conceptually than boopsi and a lot more general purpose too. Again, my personal opinion.

I have used only C++ and Java but there I dont have to care about low level details.

As it should be. When writing application code the very last thing I want to know about is the platform implementation detail, so I agree. However I also like to work in abstraction layer or lower occasionally where these things become important too.

Btw it seems in Windows you have interfaces too (in COM objects, I guess).

Even MS have OK ideas sometimes you know :-D