Re: [Liberty-eiffel] Question....

[Raphael Mack]

I also "have" to comment on this:

if you have interesting extensions to the REAL_-classes I think it is  
worth discussing them here. As - different than in C language -  
additional features are class local, they do not mess up the  
namespace, so there is no relevant limit of REAL-features. So even if  
you are the one and only user of these, it may be worth to have it in  
the core library.

Before adding new external "built_in"s it may also be worth looking at  
the external types [1], which in theory should even allow to replace  
big parts of the internal knowledge about "standard" datatypes... But:  
even when I am the one who initially suggested them in SmartEiffel  
times I am not really sure about the implementation state. - Shame on  
me ;-) and the wiki page should be updated to document the implemented  
method not the possible options anymore. - Any interests in this work  
package?

Rapha

links:
1: http://wiki.liberty-eiffel.org/index.php/External_types

Zitat von Cyril ADRIAN <address@hidden>:
> Hi Hans,
>
> I transfer this discussion to the list as it may be interesting to other
> people.
>
> 2014-09-14 10:16 GMT+02:00 Hans Zwakenberg | Ocean Consulting GmbH <
> address@hidden>:
>
> > So the questions is this redefined as:  how do I extend the
> > current REAL_GENERAL to achieve this?  Do I simply extend the
> > REAL_GENERAL.e file?  I would be fooling around rather close to the current
> > distribution, something that might make me nervous...  ;)
>
>
> The problem is that REAL_GENERAL is a very ugly class (INTEGER_GENERAL
> too). It triggers very specific behaviour deep in the compiler (including
> crooked conformane rules). You cannot just inherit from it.
>
> You could try modifying the source of the class itself.
>
> If you do so, you may need to be aware of the numerous external "built_in"
> features. Those features are compiler hooks, see:
>
>    - NATIVE_BUILT_IN -- the external feature definition, for some generic
>    checks (type of arguments, result...)
>
>
>    - EXTERNAL_ROUTINE and heirs -- the actual support of each known
>    built-in feature :
>       - what must be made alive if a built-in feature is used, i.e. collect
>       - code transformations: some "recent" (in SmartEiffel time!)
>       built-ins tend to generate equivalent Eiffel code (albeit with some
>       specific internal instructions)
>
>
>    - C_NATIVE_FUNCTION_MAPPER and C_NATIVE_PROCEDURE_MAPPER -- the actual C
>    code generation for each known built-in feature
>
>
> Cheers,
>
> Cyril