Hi Rapha,
2014-09-14 20:22 GMT+02:00 Raphael Mack <address@hidden>:
as this might be interesting for any hacker who wants to read some
details, I suggest to discuss this publicly. @all: please tell us, if you
think this is too much for the public mailing list - then we might want to
add some "liberty-internals" list. If not and you are interested follow the
discussion and start providing patches for Liberty ;-)
SmartEiffel had a private discussion list. I don't intend to reproduce the
same mistake. Development should happen exclusively in public.
Zitat von Cyril ADRIAN <address@hidden>:
too. Don't hesitate to ask questions, I am not that good at explaining the
whole architecture from scratch.
so here is one:
assume we have an expanded type FILE_TOOLS, without any attributes and
another expanded class CLASSES_TREE_FACTORY with a single attribute
file_tools: FILE_TOOLS.
The struct for CLASSES_TREE_FACTORY is reduced to an int, which is good,
but the introspection doesn't currently work with this.
So would you consider the attribute CLASSES_TREE_FACTORY.file_tools a live
feature? - I'd think so, as it IS used, we only have not to emit the
attribute into the type struct...
I see your point: I overlooked the attribute generation in se_printT(). Is
that what you mean by "introspection doesn't work"?
And: who is responsible to detect the set of live types and features?
The `collect` feature. It traverses the whole tree from the main creation
feature (the one on the command line or in the ACE file) and marks
everything alive that it can reach. Secondary roots are CECIL calls.
See CODE.collect and SMART_EIFFEL.collect_from_root
Cheers,
Cyril