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

[Karlos]

Piru wrote:
@Karlos

Maybe it should be pointed out that I also find C++ horrible bloaty nonsense and broken by design aswell.

I'd happily take Java any day, instead.

:-D You know somehow I guessed.

That being said, I still consider the "interfaces" a bad idea, regardless, at least if you're concerned in moving source between differnet platforms (that is different AmigaOS and compatibles).

How? If you write 3.x style code it compiles in OS4. Unless you are writing the libraries themselves rather than applications it need not affect you.

I firmly stand behind my claim that interfaces give absolutely no benefit at all over MorphOS.

I didn't say they did. I said I found Interfaces better by design than 3.x style libraries. I've nothing against MOS.

[Piru]

@AMIGAZ

Don't worry, this perfectly mature debate. People don't always need to agree.

[Karlos]

Piru wrote:
@AMIGAZ

Don't worry, this perfectly mature debate. People don't always need to agree.

I'm far too old for all that trolly nonsense :-D

Off topic a bit, what's your take on Objective C?

[Amigaz]

@Piru

[Karlos]

Piru wrote:
@AMIGAZ

Don't worry, this perfectly mature debate. People don't always need to agree.

No it isn't and yes they do..

/* ducks */

[Piru]

@Karlos

How? If you write 3.x style code it compiles in OS4. Unless you are writing the libraries themselves rather than applications it need not affect you.

Sure, but then you're forced to make a decision before you start coding anything. If started with OS4 interface style, and you at some later point decide you might want to create OS 3.x, MorphOS or AROS version of your program, you're upto some painstaking changes in the source code.

Also, as a final note: Interfaces are no way anything special. If you really need them, it's trivial to implement them for you current needs. In fact, interfaces are not much more than just some function pointer arrays.

What I also find stupid is forcing the interfaces to developers (or at least forcing the choice of using IFace stuff, or just old style coding), when instead they could be used if it's really applicable for the particular library. (My point being that for some new libraries where the interface actually gave some benefits it would be just fine, but it doesn't make sense to convert the existing establieshed APIs).

I didn't say they did. I said I found Interfaces better by design than 3.x style libraries. I've nothing against MOS.

I understood that, just tried to close up my argument... We're starting to drift a bit from the topic... ;-)

Anyway, at least we can agree to disagree. :-)

[Karlos]

@Piru

True about the decision, but deciding to code anything for amigaos/like stuff is a decision in itself these  days :-(

I'd argue that interfaces are a little better than function pointer arrays (and hey, I am like the worlds biggest fan of function LUT, just ask Patrik) in that at least they are not anonymous. Give me blah->method(arg1, arg2) over table[n](arg1, arg2) anyday. Don't forget that a pointer to the instance of the interface is always passed to the function implicitly too (akin to the C++ 'this' pointer), which you'd explicitly have to do for normal function pointer.

What I'd like to see is the interface concept opened up for 3.x compatibles. That would really eliminate the major objection that interfaces force you to stay on one path. Of course, that decision is well and truly out of my hands.

-edit-

Actually, thinking about what you said of the macro stuff earlier, it occured that it doesent really clash. What I mean is:

AllocVec() is just a #define for IExec->AllocVec()

It shouldn't ever clash with any other interface's AllocVec() unless you want to macroize those interface calls too.

IKarl->AllocVec() would sit happily with AllocVec() (as a define). If I needed to make it 3.x source compatible, I could always #define KarlAllocVec().

[Karlos]

Actually it is precisely due to arguments such as these that I started my own C++ framework project in the first place :lol:

Except there it extends to rather more systems than the amiga compatibles :-)

These days I shudder when I see explicit OS calls :-D

[Piru]

@Karlos

that at least they are not anonymous.

Function array don't need to be anonoymous.

Anyway, here's something I cooked up in few mins.. Just to prove the point. This is pretty much what interfaces do, but implement in scaled down single file example, with dummy functions for demonstration purposes only. Like you pointed out, the diff is that here you must pass the interface pointer explicitly.

Code: [Select]

#include <string.h>
#include <stdio.h>

struct myface
{
  int   (*foo)(struct myface *iface, char *str, int idx);
  char *(*bar)(struct myface *iface, char *str, const char *str2);
  void  (*bleh)(struct myface *iface, const char *str);

  /* data or whatever you might need */
};

static
int imp_foo(struct myface *iface, char *str, int idx)
{
  memcpy(str + idx, &quot;foo&quot;, 4);
  return 4;
}

static
char *imp_bar(struct myface *iface, char *str, const char *str2)
{
  strcpy(str, str2);
  return str;
}

static
void imp_bleh(struct myface *iface, const char *str)
{
  printf(&quot;bleh and %s\n&quot;, str);
}

void *getiface(const char *name, int x, int y)
{
  if (!strcmp(name, &quot;moo&quot;) && x == 0 && y == 0) /* whatever rocks your boat */
  {
    /* simple example, something more complex would allocate
       the new interface */
    static const struct myface face =
    {
      imp_foo,
      imp_bar,
      imp_bleh
    };
    return (void *) &face;
  }

  /* there could be different interfaces returned here,
     depending on the passed args.. whatever you need. */

  return NULL;
}

void disposeiface(void *iface)
{
  /* cleanup, if any */
}

int main(void)
{
  struct myface *IFace = getiface(&quot;moo&quot;, 0, 0);
  if (IFace)
  {
    char tmp[4];
    char tmp2[4];

    IFace->foo(IFace, tmp, 0);
    IFace->bleh(IFace, IFace->bar(IFace, tmp2, tmp));
    IFace->bleh(IFace, &quot;things&quot;);

    disposeiface(IFace);
  }

  return 0;
}


Now, is it just me or doesn't this looks just like some half-assed OO implementation for C? :-)

[Karlos]

True, you just need a constant for n. My main point is that the interface is a bit more than a function pointer table. It is the instance data too and the calling semantics to ensure that the instance data is always passed transparently to any function. For example, IExec->AllocVec(size, flags) actually compiles to IExec->AllocVec(IExec, size, flags).

-edit-

Of course, the anonymity of function LUT is one of its principal advantages. I use them for all sorts of things (presently writing a VM where the opcode value looks up a handler function, for example)...

[Karlos]

Now, is it just me or doesn't this looks just like some half-assed OO implementation for C?

It does when you see the implementation of it, yes. Of course you don't see the implementation, which is the point.

If you compare what you have just written with a typical BOOPSI object, for example, can you claim this code is not an order of magnitude cleaner and simpler? True boopsi supports more runtime flexibility (closer to smalltalk than C++) but I have never seen anybody make use this.

Also your code means that foo() and bleh() are no longer nasty globals so it won't clash with the interface I might want to add. After all, foo() is the most fundamental method ever named :-D

-edit-

Surely you can see an inherent charm in the approach of your code over a 3.x library that defines a global foo() and bleh() ?

Namespacing aside, you implemented it totally in C, no asm, pragmas or other stuff. Hence it is potentially portable across more than the amiga range of platforms.

[Piru]

Also your code means that foo() and bleh() are no longer nasty globals so it won't clash with the interface I might want to add.

Yeah, and that's the point. Here you use the interface, since you're going to add some another implementation. But in general, such construct is not needed (if you always use one set of functions for example).

In general, IMO such construct doesn't offer anything in itself that would justify it. Only in cases where you really are going to have different implementations it might pay off (esp if used locally inside a program or between program and plugins, without some sucky global libraries).

Surely you can see an inherent charm in the approach of your code over a 3.x library that defines a global foo() and bleh() ?

Namespacing aside, you implemented it totally in C, no asm, pragmas or other stuff. Hence it is potentially portable across more than the amiga range of platforms.

Nope, if it means you break all source code compatibily to old systems that had foo(), bar() and bleh() in the API using normal library. If this was some new library that actually benefited from the interface (different implementations used internally), then it would potentially pay off.

You can implement library fully in C as you're aware, I'm sure. Pragmas, inlines and other stuff is easily generated from whatever "library definition" you might use (be it XML or fd + protos).

Also, as a sidenote: if the original library defined the foo, bar and bleh functions, they really aren't global. They're actually the base + offset (and base can change per opener, like happens with bsdsocket!). You're not limited to using inlines, you can well use other means of calling them... Naturally if you use #define inlines then they're global namespace, but there is no need for this to be, nor is the limitation set by the actual library implementation in any way.

[Karlos]

Piru wrote:

Nope, if it means you break all source code compatibily to old systems that had foo(), bar() and bleh() in the API using normal library. If this was some new library that actually benefited from the interface (different implementations used internally), then it would potentially pay off.

Now here, I think is the difference between us. For me, the backwards compatibility issue is an implementation detail. I'm more interested in what I can do with an interface rather than how it replaces the old library call. I look at them as a foundation for runtime loadable class implementations more than a simple library mechanism. That happens to holds a lot of interest for me.

You can implement library fully in C as you're aware, I'm sure. Pragmas, inlines and other stuff is easily generated from whatever "library definition" you might use (be it XML or fd + protos).

Yes, of course, but what I meant is, your example is portable and clean across multiple platforms without the need for these other components. The 3.x library interface s not.

Also, as a sidenote: if the original library defined the foo, bar and bleh functions, they really aren't global. They're actually the base + offset (and base can change per opener, like happens with bsdsocket!). You're not limited to using inlines, you can well use other means of calling them... Naturally if you use #define inlines then they're global namespace, but there is no need for this to be, nor is the limitation set by the actual library implementation in any way.

Yes but using these alternative mechanisms to access the library functions are no more 3.x source compatible than interfaces would be.

[Karlos]

@Piru

:lol: we are so off topic :-D

[Piru]

@Karlos

Now here, I think is the difference between us. For me, the backwards compatibility issue is an implementation detail. I'm more interested in what I can do with an interface rather than how it replaces the old library call. I look at them as a foundation for runtime loadable class implementations more than a simple library mechanism. That happens to holds a lot of interest for me.

Right. I'm sure these things are fine for your projects.

But for OS: I actually want to see what real benefits some new system might give, before actually implementing it all over the place. I'd rather keep things like they are unless if the benefits are really worth the trouble of the change. For some particular cases the interface calling method surely pays of, but not everywhere.

Yes, of course, but what I meant is, your example is portable and clean across multiple platforms without the need for these other components. The 3.x library interface s not.

Yeah it is portable (while OS4 interfaces are not). If you need portability and such construct, you'll end up implementing something very similar anyway (or using C++)... :-)

Yes but using these alternative mechanisms to access the library functions are no more 3.x source compatible than interfaces would be.

True. That wasn't the point here, but disproving the claim that the functions would somehow be global.

we are so off topic

We are, but I still try to point out that enforcing interfaces to old APIs was actually a mistake, not a benefit. :-)

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