Re: Eu improvements (part 4)
- Posted by Karl Bochert <kbochert at copper.net> Jan 06, 2007
- 689 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