1. Yet another OO aproach
- Posted by Daniel Berstein <daber at PAIR.COM> Jun 05, 1998
- 595 views
- 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
- Posted by Robert Craig <rds at EMAIL.MSN.COM> Jun 07, 1998
- 599 views
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
- Posted by Terry Constant <constant at FLASH.NET> Jun 07, 1998
- 602 views
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