1. Is there anyway to reach it?

2. It's when I create an Iterator and get an program as argument to create() and I want to make sure that the program is the kind of class it should iterate over.

something like this

PIKEFUN void create(program l) { if (l is a LinkedList) <-- how to solve this? { then init } else { Throw error } }

/ Peta, jo det är jag

Previous text:

2003-01-24 11:20: Subject: Two questions

---

1. For this you should read Finnman's report. :-)

2. What do you mean by "kind of program"? What problem are you

actually trying to solve?

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Regarding combining a C and Pike module (which didn't really get any answers), I suggested the Image method; using a magic `[] in ADT.pmod for looking up identifiers from an _ADT module written in C. (Image does it the other way around, though.)

If there is a better way of doing this, now is a good time to say so.

/ Johan Sundström (a hugging punishment!)

Previous text:

2003-01-24 11:49: Subject: Two questions

---

1. Is there anyway to reach it?

2. It's when I create an Iterator and get an program as argument to

create() and I want to make sure that the program is the kind of class it should iterate over.

something like this

PIKEFUN void create(program l) { if (l is a LinkedList) <-- how to solve this? { then init } else { Throw error } }

/ Peta, jo det är jag

I think it is good practice to use distinct names for the lower level C module and the corresponding Pike module. Having Foo.pmod inherit Foo.so (if that's what you're suggesting) seems unnecessarily obscure to me. I'd prefer Foo.pmod to inherit _Foo.so (and the latter will also work in the obvious way if _Foo is statically linked).

/ Niels Möller ()

Previous text:

2003-02-03 14:45: Subject: Two questions

---

The standard way is to write the base functionality in C, and then inherit that from the Pike code, adding the higher level functionality. No _Foo module is needed, just make a src/modules/Foo.pmod.in with the Pike code.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

To me, it's an advantage that _Foo "leaks" into the global namespace. Should makes it easier to track down problems if you can look at the lower-level things without filtering them through Foo.pmod.

The point of the "_" prefix is just to say that this is a low-level interface that it's not recommended that anybody but the Foo module accesses directly, and that's what I would usually want for such an "internal" C module.

/ Niels Möller ()

Previous text:

2003-02-03 14:51: Subject: Two questions

---

It has the disadvantage of exposing _Foo to the global module namespace though. And module.pmod.in works with statically linked modules as well.

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)