Mikael Amborns facet implementation is finally checked into Pike. Facets allows you to enforce that a multiple inheritance is used when functionality is split into several classes.
One current misfeature is that the facet group object needs to exist before (e.g. loader wrapper) or be created during compilation (e.g. .pmod file).
Usage example:
add_constant( "Bunny", FacetGroup() );
(1) Result: 0
class White { facet Color:Bunny; } class Black { facet Color:Bunny; } class Small { facet Size:Bunny; } class Large { facet Size:Bunny; } class Snuffy { inherit White; inherit Small; } class Sooty { inherit Black; }
Compiler Error: 1:Error in some product classes Compiler Exception: Product class does not inherit from all facets. _static_modules.Builtin()->facet_group: _static_modules.Builtin()->facet_group()->check_product_classes()
class Checkers { inherit Black; inherit White; }
Compiler Error: 1:Unable to add product class Compiler Exception: Product class can only inherit from one class in every facet. _static_modules.Builtin()->facet_group: _static_modules.Builtin()->facet_group()->add_product_class(65713,0,65701)
Another problem is that it leaks all kinds of stuff (parser stack, objects and strings)...
Interesting. Can several independent facet systems be used at the same time?
Why are facet errors thrown as exceptions? I'd expect them to be normal compiler errors. Do the leaks affect code that doesn't use this? Are somewhat more extensive docs in the works? Where's the test suite?
Can several independent facet systems be used at the same time?
I think that is the intention.
Why are facet errors thrown as exceptions?
I don't know.
Do the leaks affect code that doesn't use this?
No. It's the parsing of facets that leaves stack droppings and it is the facet group object that is leaked.
Are somewhat more extensive docs in the works?
http://pike.ida.liu.se/docs/docs/MikaelAmborn_Facet_Thesis.pdf
Where's the test suite?
Not yet.
Correction: It is currently not possible to have a class belong to two facet-groups.
Another question is if perhaps it is better to let the compiler always create the facet group object when it first encounters the facet keyword, and by implication having the object group "argument" be a program instead of an object. If so, is it possible to have the facet group definition and the facet users in the same file, if the facet is "updated" on the second compiler pass.
After a quick look at the implementation, it doesn't appear to be easy to extend it to support several independent facet groups. I base that primarily on that there's a single dedicated pointer for the facet group in the program struct.
Can things like "currently not" and "not yet" be interpreted as "going to be fixed soon"? The reason I ask is that thesis workers rarely continues after the thesis has been accepted.
I don't think Mikael is going to do it, if that is what you are asking. Hopefully, someone else<tm> will continue his work.
I sort of figured that. As it is now there's prototype quality written all over it, and I have a hard time getting very thrilled over that since I know from experience that twice as much work, at the very least, remains to make it heavy duty production quality.
In general I don't see much gain from the pike language point of view that it's becoming a bin for half-baked thesis works (not necessarily implying that all the thesis works are that way; I haven't investigated them all in detail). Also, even if the code itself might be fine, its usefulness is imo severely diminished by the fact that the guy who wrote it invariably disappears shortly after the first check-in.
Otoh I don't have much of a problem with them as long as they don't get in the way. This one adds a "facet" declaration to the core language. Can the deficiencies be fixed without changing the current semantics? Or alternatively, should we label it "experimental" and guarantee no compatibility whatsoever?
Before getting all worked up we should see what Mikael has to say. He was fairly enthusiastic about actually getting it into Pike and have it used.
pike-devel@lists.lysator.liu.se
-
Marcus Agehall (PacketFront) ＠ Pike (-) developers forum -
Martin Nilsson (DivX Networks) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Lundqvist (disjunkt) ＠ Pike (-) developers forum