Newbie questions about Pliant

Newbie questions about Pliant

'Conditional' types

Is it there ?
Message posted by maybe Ivan Gudym on 2001/11/15 09:12:01
Is there in pliant some sort of 'conditional' type ?
I mean something like:

type typename
  field Type1 field1
  switch discriminator
  case One
    field Type2 field2
  case Two
    field Type3 field3

And usage:
  x:field1:=XXX
  x:One:field2:=XXX
  y:Two:field3:='YYY'
Message posted by maybe Ivan Gudym on 2001/11/15 12:30:38
I meant, like C 'union' one
Message posted by pom on 2001/11/15 23:57:38
There is no such construction, but it could be implemented by a meta if
there is a need for it.
Message posted by maybe Ivan Gudym on 2001/11/16 07:28:30
It already needed, porting C headers require such a construction.
I undesrtand, that union in C stuct can be in most cases replaced by
greatest field in union, but not in all. And second point - porting
can be more formal procedure if such construction exists, just formal
replace C types to pliant types and so on.
Maybe someone create such a meta ?
Message posted by maybe Ivan Gudym on 2001/11/16 07:28:46
It already needed, porting C headers require such a construction.
I undesrtand, that union in C stuct can be in most cases replaced by
greatest field in union, but not in all. And second point - porting
can be more formal procedure if such construction exists, just formal
replace C types to pliant types and so on.
Maybe someone create such a meta ?
Message posted by maybe Hubert Tonneau on 2001/11/19 19:40:34
The main problem is that it is ambigious:
if you have something like:

type Test
  ...
  union u
    field Int i
    field Str s
  ...

when an object with type 'Test' is freed, should we assume that the 'u' is
'i' or 's' ?

Basically, 'union' is a C feature that does not scale well to C++ or Pliant
level. It could be done, but raises a number of issues unless all elements
in the union are scalar datas.
Message posted by maybe Patrice Ossona de Mendez on 2001/11/19 22:12:35
What concerns C++, the problem has been solved by restricting
union members:
"An object of a class with a  non-trivial default  constructor,  
a  non-trivial copy constructor, a non-trivial destructor,
or  a  non-trivial  copy assignment operator  cannot be
a member of a union, nor can an array of such  objects."

Actually, two kind of problems may lead to a "union-like"
construction: either some datas may be accessed in a multiple
way through simple memory maping (this mainly concerns scalar types)
or it is a way to build a kind of "Universal container", in which case
a field should act as a discriminator. The discriminator then induces
the choice of the destructor used for the union, and a change of discrimator
leads to the destruction of the previous union data and a construction of
the new one according to the discriminated type.

The first case may be solved easily by introducing some maping methods to
the type; the second one is probably not so good and a construction based
on universal pointers should probably be prefered (a field would then
be an arrow or a link to some base type with generic methods).