OpenEuphoria

Re: Eu improvements (part 4)

• Posted by Karl Bochert <kbochert at copper.net> Jan 06, 2007
• 659 views

Pete Lomax wrote:
> 
> Pete Lomax wrote:
> > 
> Yeah, Cut that middle bit of nonsense, subsequences rule, no flattening:
> > }}}
<eucode>
> > type Point(sequence p)
> > enum integer x, y       -- x=1, y=2
> > --  if length(p)!=2 then return 0 end if        -- automatic
> > --  if not integer(p[1]) then return 0 end if   -- automatic
> > --  if not integer(p[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > type Point_3D(sequence q)
> > enum Point p, integer z -- p=1, z=2
> > --  if not Point(q[1]) then return 0 end if     -- automatic
> > --  if not integer(q[2]) then return 0 end if   -- automatic
> >     return 1
> > end type
> > 
> > Point_3D A
> >  A={{1,1},1}
--I think you are discarding something valuable if you expose the
--innards this way. Think about the versioning of external libraries

> >  ?A.p.x -- same as A[1][1], note A[p][x] gives p undefined
> >         --                   and A[1][x] gives x undefined
> >  ?A.p.y -- same as A[1][2], note A[p][y] gives p undefined
> >         --                   and A[1][y] gives y undefined
> >  ?A.z   -- same as A[2], note A[z] gives z undefined
> > </eucode>
{{{

> >
Why do I have to know that Point_3D was extended from Point, rather than
defined all-at-once?
Why should one co-ordinate be so different from the others?
If a function operates on a Point, should it also operate on a Point_3D?
Flatten the sequence!
 
> Agreed, you're right, much happier with that now.
> Yes, obviously you can put user defined code above the return 1.
> 
> Thanks,
> Pete