OpenEuphoria

Re: Eu improvements (part 4)

• Posted by Pete Lomax <petelomax at blueyonder.co.uk> Jan 06, 2007
• 863 views

Karl Bochert wrote:
> I'd look at Hoffman's thead if I could find it.
I remember seeing it, but I can't give you a link...

I scribbled some rubbish, probably along the same lines, which I guess I should
post for reaction:

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 p)
enum Point, integer z   -- x=1, y=2, z=3
--  if length(p)!=3 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
--  if not integer(p[3]) then return 0 end if   -- automatic
    return 1
end type

--which allows:
Point_3D A
 A={1,1,1}
 ?A.x   -- same as A[1], note A[x] gives x undefined
 ?A.y   -- same as A[2], note A[y] gives y undefined
 ?A.z   -- same as A[3], note A[z] gives z undefined

--or (?better I think?):
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

--which needs:
Point_3D A
 A={{1,1},1}
 ?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

Something there, maybe, not sure I'm happy with it...

> I think the reurn value is the most important advantage.
> I think transparency here is bad. PBR is different than normal parameter
> passing, and I want to know which is being used when I read the code.
> As an aside, this is what bothers me so much about OOP programming. So
> much is being done transparently (behind my back) that reading the code
> gives me no idea what is actually happening.
Oh, snap!
> 
> > One problem with PBR is that it shouldn't surprise the programmer. 
Snap!

> For me, clarity of the resultant code is the measure of all features.
Bingo!

Regards,
Pete