Nilsson, did you have any good way of inserting Regexp.PCRE?
I want to write the glue in lib/modules, but I'm getting fuzzed by the compilation orders (again). Is it supposed to work like this?
1) I moved Regexp (the c+pike glue) to Regexp.Builtin, using MODULE_INIT() location setting
2) I make Regexp.pmod/module.pmod inherit Regexp.Builtin, and then this happens:
| > Regexp("["); | Cannot call undefined lfun `(). | > indices(Regexp); | (1) Result: ({ /* 11 elements */ | "`()", ...and the rest that should be there... | "Builtin", | "module", | "___Builtin", | }) | > Regexp["`()"]("hej"); | (2) Result: Regexp.SimpleRegexp(hej)
There's nothing magical about the old Regexp module,
| SimpleRegexp `()(void|string regexp) { return SimpleRegexp(regexp); }
so what's going on? Why does `[] work but not `->?
| > Regexp.PCRE("(\1234.).*n")->split2("p\1235ke \1234s fun"); | (4) Result: ({ /* 2 elements */ | "\1234s fun", | "\1234s" | }) | > Regexp.PCRE.split2("(\1234.).*n","p\1235ke \1234s fun"); | (2) Result: ({ /* 2 elements */ | "\1234s fun", | "\1234s" | }) | > Regexp.PCRE.split("(\1234.).*n","p\1235ke \1234s fun"); | (3) Result: ({ /* 1 element */ | "\1234s" | }) | > Regexp.PCRE.Plain("(\1234.).*n")->split2("p\1235ke \1234s fun"); | Bad argument 1 to pcre->create(). Expected string (8bit) | :-)
So, to check this in I need to move away Regexp like in the commented text. Any ideas?
/ Mirar
Previous text:
This is even more interesting,
Regexp.pmod/Module.pmod: | class Foo | { | inherit Regexp.Builtin; | }
| > indices(Regexp.Foo); | (2) Result: ({ /* 1 element */ | "_SimpleRegexp" | }) | > indices(Regexp.Builtin); | (3) Result: ({ /* 6 elements */ | "replace", | "`()", | "split", | "SimpleRegexp", | "match", | "_SimpleRegexp" | })
Er... Okey?
/ Mirar
Previous text:
A lot.
I'm starting to doubt if it's worth all this trickery to get a cleaner namespace. Clearly the module structure doesn't handle a name doubling as a class and a module. It's not only about the call API but also typechecking, inheritance etc. Why not use PCRE on the top level instead? It's not exactly likely that it'll conflict with anything else.
/ Martin Stjernholm, Roxen IS
Previous text:
Yes it's possible to inherit modules, provided that they aren't dirnodes or joinnodes. I've thought about solving the dirnode issue by essentially removing dirnodes altogether (especially the `[] and `-> lfuns in them). Joinnodes are harder to do away with. A solution for that case is probably to add a callback in the compilation handler that can extract a suitable class from the joinnode (or complain).
As for typechecking, it would be necessary that e.g. Regexp and Regexp.Regexp compare as equal, but only when Regexp is used as a class. It's not possible to solve well.
/ Martin Stjernholm, Roxen IS
Previous text:
A dirnode is the object that represents a .pmod directory. It has `[] and `-> lfuns that looks for identifiers in the directory or in the special module.pmod file.
Joinnodes are used when several module directory trees contain the same module, e.g. if the module path contains /foo and /bar and there's a /foo/Gnu.pmod and a /bar/Gnu.pmod then you'll get a joinnode for Gnu which looks up every identifier in both.
/ Martin Stjernholm, Roxen IS
Previous text:
No, it hasn't.
String;
(1) Result: master()->joinnode(({ /* 1 element */ master()->dirnode("/home/nilsson/Pike/7.5/lib/modules/String.pmod") }))
String["capitalize"];
(2) Result: String.capitalize
String->capitalize;
(3) Result: 0
This usually bites me when I write testsuite cases (cond(foo->bar)), but I have assumed that sometimes you might want to call things in the actual dirnode so I haven't fixed this.
/ Martin Nilsson (saturator)
Previous text:
pike-devel@lists.lysator.liu.se
-
David Gourdelier -
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Martin Nilsson (saturator) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Mirar ＠ Pike developers forum
-
Per Hedbor () ＠ Pike (-) developers forum
-
Peter Bortas ＠ Pike developers forum