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

[Karlos]

@Piru

Regarding the OS:

I don't argue with you that replacing the old mechanism causes some issues. I am sure that doing so, was to bring about a cleaner system in the long run. Phasing out old stuff gradually can be messy. Heck, I'm using windows here, the king of half baked transformation. They (the OS4 developers I mean) wanted something more powerful to replace libraries and took the opportunity to implement it at a time when the whole OS was undergoing fundamental rework anyway, so I don't begrudge them that decision.

Now as for benefits, I really do see things like heirarchial driver sets, plugins, datatypes, gui objects and all such things that are inherently OO by nature can benefit from the new model, since, well it is an OO design.

[Piru]

@Karlos

They (the OS4 developers I mean) wanted something more powerful to replace libraries and took the opportunity to implement it at a time when the whole OS was undergoing fundamental rework anyway, so I don't begrudge them that decision.

Actually my understanding is that the interface sheme was brought pretty much as-is from some "semi-dead" AmigaDE project. (I could remember wrong though). Yet, enforcing it to all existing old OS APIs, I will never understand what kind of brain malfuction made them to do that. It just doesn't make any sense (well, to me at least).

Now as for benefits, I really do see things like heirarchial driver sets, plugins, datatypes, gui objects and all such things that are inherently OO by nature can benefit from the new model, since, well it is an OO design.

They're OO to the outside at least, but the internal original implementation is far from it (existing components from previous OS versions). Just converting these to new system for sake of it (and without actually getting any real benefit from the conversion!), is that really worth the trouble? IMO not.

Certainly some totally new systems that are coded to take advantage of the new features would pay off.

But yet again, just converting all old systems to use interfaces: Just extra work without any real benefits, and causing source compatibility issues.

[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 :-)

[itix]

1) An interface defines a namespace. This allows me to create my own interfaces that have function names that would otherwise clash with the OS ones. IKarl->AllocVec() is totally different from IExec->AllocVec(). Both can happily coexist in the same source.

This doesnt work for libraries which are ported from link libraries. For example I cant imagine you edit every single SDL port to call SDLIFace->SetVideoMode() instead of SetVideoMode() ?

As a more tangible example, consider MUI/Reaction etc. The BOOPSI calling mechanism is just awful. Reimplementing them using interfaces would likely give more compact code that could run a hell of a lot faster. I am sure a button->DoLayout() is an order of magnitude faster than a DoMethod() call via the boopsi dispatcher

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

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. In practise you are trying to create a class from library base.

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 is major difference between them.
 

[redfox]

@Edpon

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

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

redfox

[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.

[Acill]

Well you both killed the poor guys topic!

To get back on track and to help you out, OS4 and MOS both have good things in them. As to the better OS thats up to the end user. I for one have used MOS since the PEgasos came out and like it much better then OS4. I would like to see OS4 on the Pegasos II to give it a chance, but I still feel MorphOS is by far the etter choice. Again its all up to the end user.

[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.

[x56h34]

Who is the better programmer? Karlos or Piru? :-P

[Amigaz]

 :lol:  :lol:  :banana:  :banana:

[Amigaz]

 :lol:  :lol:  :banana:  :banana:

[Framiga]

"Who is the better programmer? Karlos or Piru?"

i have no idea! but i love them both :-)

[Darth_X]

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

[Framiga]

the community behind could be the factor.

Its a matter of taste . . . i have friends and "enemies" on both sides, so :-)

[Doobrey]

x56h34 wrote:
Who is the better programmer? Karlos or Piru? :-P

It'll be the one with the biggest beard, bad personal hygiene and no girlie.

And looking at Piru's avatar, he's not old enough to grow a beard or date  ;-)