1. Yet another OO aproach
- Posted by Daniel Berstein <daber at PAIR.COM>
Jun 05, 1998
-
Last edited Jun 06, 1998
Here's my contribution to the euphoria object oriented thread:
type myobject (datatype x) [attribute_only]
attribute new
x = explicit definition of the data structure
or
x = myconstructor() -- external function
end attribute
[private] attribute method_name [(parameters)]
-- method code
end attribute
-- normal type cheking
end type
1.- If attribute_only is specified object can only be set/read using defined
attributes (methods).
2.- The 'new' attribute is mandatory, and act as the constructor. When a new
object is declared the compiler calls this method.
3.- The object-variable must be passed by reference to the methods.
Example:
type coord (atom x) atribute_only
attribute new
x = 0
end attribute
attribute get
return x
end attribute
attribute set (atom n)
x = n
end attribute
end type
type pair (sequence x y)
attribute new
coord x, y
xy = {x,y}
end attribute
attribute getX
return xy[1].get
end attribute
attribute getY
return xy[2].get
end attribute
attribute setX (integer x)
xy[1].set = x
end attribute
attribute setY (integer y)
xy[2].set = y
end attribute
end type
pair mypair -- The compiler automatically calls mypair.new,
mypair is {0,0}
mypair.setX = 10 -- mypair is {10,0}
mypair[1].set = 10 -- Has the same resultas setX. 'set' is an attribute
of coord.
-- You can do this because pair hasn't
attribute only.
mypair[1] = 10 -- ERROR, coord atrribute_only is set!
? mypair.getY -- Outputs '0'
mypair.new -- Default pair {0,0}
This method provides encapsulation (attribute_only), inheritage, and
polimorphism. Think of it as an extension to 'type'. It's not inteded to be
handled by a preprocessor, but be hardcoded into Euphoria.
Pros:
- Clear sintax
- Doesn't break existing code
- No big performance cost
Cons:
- Not pure OO
- Only completly private or completly public data
Comments, suggetions? What do you think Rob?
Regards,
Daniel Berstein
daber at pair.com
2. Re: Yet another OO aproach
Re: OO
Thanks Daniel for the suggestions.
I need time to absorb everyone's ideas on OO.
I encourage people to keep experimenting.
Re: File Handling
It might be reasonable for me to put out an
official .e file for those file functions. Thanks Daniel
for the code you sent via private e-mail. It seems
to work fine with 8.3 names but it's not aware of
long filenames. (I'll put it on the Recent Users Contributions page
later today.)
Re: exit codes / system
I will do some experiments. I think I can get
the exit code as part of a new system()-like
function that does not start a new shell (the way
the current system() procedure does.)
Regards,
Rob Craig
Rapid Deployment Software
3. Re: Yet another OO aproach
Robert Craig wrote:
>
> Re: OO
>
> Thanks Daniel for the suggestions.
> I need time to absorb everyone's ideas on OO.
> I encourage people to keep experimenting.
>
Rob,
One of the reasons I like Euphoria is because it is not OOP. I could
accomplish all about OOP that I am interested in with an addition in
scope for variables and functions. Let me describe the present scope
rules, as I understand them, from a pointed perspective.
• Global routines, variables, and constants are available to all source
files once they have been included.
• All other routines are private to their source files.
• Variables and constants outside of routines are private to their
source files and available to any routines in their source files after
they are declared.
• All variables declared in routines are private to their routines.
I have worded this description on purpose using only global and private
descriptions. What I would like is another scope. For purposes of this
e-mail, I will use the term, public.
Routines, variables, or constants declared as public would be available
to their own source files and to source files that include the files
they are declared in. They would be accessible by a special notation.
Let me give some concrete examples.
---------
MyInc.e
global sequence gs
public sequence ps
sequence s
global procedure gp()
puts(1,"in gp")
end procedure
public procedure pp()
puts(1,"in pp")
end procedure
procedure p()
puts(1,"in p")
end procedure
--------
MySrc.ex
sequence ps
ps = "assigned to variable in this file"
--now assign to a public variable
MyInc.ps = "assigned to public variable in include file"
gs = "assigned to global variable"
procedure pp()
puts(1,"in MySrc"
end procedure
pp() -- would display "in MySrc"
--now a call to a public routine
MyInc.pp() -- would display "in pp"
gp() --would display "in gp"
--------
I don't know if the "MyInc." notation is best, I like it. I don't need
nor do I want all the complications of OOP in creating and destroying
objects. An approach like this gives me modularity and allows me to
protect variables and routines, while at the same time being able to use
the same identifiers in multiple .e files without conflict.
>
> Re: exit codes / system
>
> I will do some experiments. I think I can get
> the exit code as part of a new system()-like
> function that does not start a new shell (the way
> the current system() procedure does.)
>
Such a function would be truly appreciated and used by me.
--
Terry Constant
constant at flash.net
