liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] Array with integers. real and strings


From: Germán Arias
Subject: Re: [Liberty-eiffel] Array with integers. real and strings
Date: Mon, 28 Mar 2016 01:39:55 -0600

El lun, 28-03-2016 a las 01:21 +0200, Paolo Redaelli escribió:
> Il 27/03/2016 21:23, Germán Arias ha scritto:
> > Hi,
> >
> > Is posible have an array/native array with integers, real and strings? I
> > try with ARRAY[ANY], but don't work. Or maybe a tuple with different
> > types? The problem is that I don't know. beforehand, the order of the
> > arguments. This is, something it can be: integer, string, integer, .....
> > and others: string. string, real,... And I need pass it to a C
> > function. 
> What kind of problem are you trying to solve?
> I don't want to prejudge but this kind of issues raise when you try to
> solve a problem in Eiffel in a mostly unEiffellish way.

The C function to create preferences panels needs an array with the
address of the initial values. It can be integers, floats or strings.
But I can't do something like 3.to_pointer to pass the address of an
integer in an array of pointers. So, maybe a better solution is pass all
as strings (maybe with extra information) and then do the work in the C
side.

Germán

> 
> INTEGERs and REAL are expanded classes, while string-like classes are
> reference string.
> All the heirs of ABSTRACT_STRING are reference classes actually. In fact
> it is usually better to use ABSTRACT_STRING instead of STRING whenever
> possible as queries arguments since you may that way provide a ROPE, a
> STRING, a FIXED_STRING, a LAZY_STRING and so on....
> It is not possible to mix expanded and reference classes in the same
> container as they don't have a common inherited anchestor: all expanded
> classes insert the features of ANY but they don't conform to ANY.
> You may use VARIANT and TYPED_VARIANT to achieve this but that's somehow
> clumsy.
> GObject had the same issues and solved them having variant-like,
> reference classes that acts like a union.
> 
> You may take a look at the quick hack I wrote in this branch
> https://github.com/tybor/Liberty/tree/variant and in particular
> https://github.com/tybor/Liberty/blob/variant/tutorial/variant_usage.e
> I've put into a ephemeral branch because of the change I made to
> TYPED_VARIANT.out which may not be wanted as a language-wide change.
> 
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]