Final Fantasy 2 based gamesource code

[Arne Vajhøj]

If you don't elaborate the struct in a header file, then people can't
bypass the interface.

In many libs the opaque context patterns are widely used.

Illustration:

foobar.h
--------

#ifndef FOOBAR_H
#define FOOBAR_H

typedef void *FOOBAR_CTX;

void foobar_init(FOOBAR_CTX *ctx);
void foobar_set_v(FOOBAR_CTX ctx, int v);
int foobar_get_v(FOOBAR_CTX ctx);
void foobar_destroy(FOOBAR_CTX ctx);

#endif

foobar.c
--------

#include <stdlib.h>

#include "foobar.h"

struct FOOBAR
{
int v;
};

void foobar_init(FOOBAR_CTX *ctx)
{
*ctx = malloc(sizeof(struct FOOBAR));
}

void foobar_set_v(FOOBAR_CTX ctx, int v)
{
((struct FOOBAR*)ctx)->v = v;
}

int foobar_get_v(FOOBAR_CTX ctx)
{
return ((struct FOOBAR*)ctx)->v;
}

void foobar_destroy(FOOBAR_CTX ctx)
{
free(ctx);
}

which nicely encapsulates the definition.

It can be combined with function pointers if necesarry.

Arne

 

[Arved Sandstrom]

On 03/23/2013 08:12 AM, Chris Uppal wrote:
[ SNIP ]

(By the way, a stronger argument, IMO, for /not/ regarding the C-based stuff as
"true OO" is that C lacks GC -- the longer I work in OO the more I move towards
seeing GC as /essential/ since without it the objects don't have full autonomy.
That's not part of the popular/consensus view of OO, though.)

-- chris

What I think is important is that you can clearly define your object
lifetimes. GC is not even an OO concept, it's automated reclaiming of
memory no longer used by a program. C has garbage collectors available too.

If you implement OO in C in such a way that it's clear what object
lifetimes are, that's what matters. IMO.

AHS

 

[Joshua Cranmer ðŸ§]

All interfaces are abstract in Java so in the context of a discussion in
a Java group I don't see the point.

We're discussing an abstract programming concept so by the term
"abstract interface" here I meant to refer to the theoretical concept
rather than the Java specific term. Although it turns out that Java's
interfaces map very nicely to abstract interfaces and vice versa.

I don't see it I'm afraid

Per my definition, it boils down to three things: abstraction,
polymorphism, and inheritance. Function pointers I hope we can both
agree satisfy polymorphism. Inheritance of implementation comes about by
having something like this:

int SuperStack_pop(Stack *s) {
int rv = Stack_pop(s);
/* do something else */
return rv;
}

Not as elegant as Java, but it works.

For the abstraction paradigm, note that it is possible to provide two
different implementations of stack methods that use the same interface.
You could use a sentinel stack, a circularly-linked list stack, or a
regular no-sentinel stack. You could get even more creative if you
abused the ability to type-pun in C and made the top node pointer do
something else. If it were a plain void *pImpl member (as is more common
in C OOP libraries) that the "class" could allocate at well, then
there's no limit to how many different implementations.

This doesn't alter the fact that my C code is not Object Oriented

I would say you're thinking about it in the wrong terms. Programming
paradigms are nothing more than philosophies to structure code, so you
could easily write declarative, imperative, functional, and
object-oriented code all in the same language, and even the same code.
This is why I dislike calling languages "functional", "object-oriented",
etc.: it obscures the fact that these terms have really fuzzy boundaries
when applied to real-world languages and that what you have at best is a
spectrum that really refers to how easy it is to do something.

 

[bubble]

Hi,

You need to learn object-oriented programming, and Java.

Thank you for your advice, it was most helpful.

I will try to put in the corrections if I find the time.

HAND,
Fyndhorn Elder

 

[Arved Sandstrom]

On 24/03/13 04:01, Joshua Cranmer 🧠wrote:

[ SNIP ]

Wow, and I thought it was just me. The fact that science and philosophy
are so inextricably linked came as a surprise to me at first but they
are. You are absolutely right and philosophically I see OO as an
holistic approach to software engineering. Something is either OO or it
isn't. The fact that you can write code that 'looks like' OO in C or
Pascal or CPM or Dr Logo or FooBar language come to that is irrelevant
to me. Philosophically I see OO as a state of mind. the 20'000 ft view
of an OO system is of a number of semi-autonomous Objects existing in an
abstraction of our reality that pass messages between themselves to
implement a human concept. And I make no distinction here, Every single
concept that has ever been conceived by the computer age sentient beings
that inhabit this planet is a human concept, there are no exclusions. I
think that a language that is OO should provide the tools to implement
these abstractions in a way that removes the 'difficult bits' If I want
to think about memory addresses I'll use C or asm, If I want to do OO
I'll use Java, as you say, language choice can be simply about "how easy
it is to do something". At best my C stack is an incomplete OO
implementation. This is why I don't see it as OO, something that is
incompletely Object Oriented can't be Object Oriented.

Than you for a very enjoyable discussion

lipska

Interesting discussion, a couple of observations.

First, to me if something "looks like" OO then it really is, because I
can't think of any sensible use of the word "resemble" in this context
other than taking it to mean: "I examined the code and found it to be OO
code". How does something look like OO and not be OO? Maybe if you
failed to examine thoroughly, is all.

As for any black and white definition of what is, and what isn't, OO, it
doesn't exist. Read the section on fundamental features & concepts in
http://en.wikipedia.org/wiki/Object-oriented_programming. For example,
although this would surprise a lot of OO programmers, the class concept
is not even close to being a core requirement for OO, and as you can see
from that article the number of generally agreed fundamental features is
small.

So I wouldn't use the term "incomplete" at all unless one or more of
those 3 (or maybe 4) fundamental features is missing.

AHS

 

[Stefan Ram]

We're discussing an abstract programming concept so by the term
"abstract interface" here I meant to refer to the theoretical concept
rather than the Java specific term. Although it turns out that Java's
interfaces map very nicely to abstract interfaces and vice versa.

The definition of »Java interface« we get from the JLS.
What is an »abstract interface«?