Re: Euphoria Object Oriented Programming
Hi Matt,
Thanks for the answers! This is really great that you've done most of the work
already :)
Rob, what do you think, could this OOP functionality be added to the RDS
Euphoria too some day? I just think that this is such an important thing that it
would be good if it was shipped with the main distribution.
> With the exception of the static classes and
> private members, ooeu can do everything you're
> asking about. I think the private members could be
> implemented fairly easily, they just haven't been
> at the top of the list of things to do.
Well I think static classes aren’t so important, but private members are. Do you
have some timetable about when you plan to add support for them?
> ooeu allows as many constructors as you like
Great!
> ooeu uses dot notation
Double great!
> The 'new' doesn't really add anything here
True, your way is better.
> I think that if you don't have inheritance,
> you've destroyed a big reason for using OOP: code reuse
I agree. I meant that in my opinion it’s not in the first priority. But again,
it’s great you’ve already done that part too :)
> I have some ideas on how to get virtual functions into ooeu
> which will make it truly oop. ... Now that the backend is
> open source, I'm not so constrained, since you can get
> fast operation from ooeu with the c backend.
Well, this would be superb if you can get it working :)
> > This should be too hard to code?
> Heh, take a look at the source and decide for yourself. :)
Heh, I had a typing mistake here. I meant to write shouldn’t :)
Best regards,
--Tapani Talvitie
Tapani Talvitie wrote:
>
> Although variable types and scopes are superb in Eu, I still miss classes.
> Namespace
> identifiers solve only a part of the problem, since they only enable static
> instances. In my opinion, classes are quite necessary for large programs.
>
> I noticed that there's been a lot of debate over OOP in here, but what's the
> current status? Is RDS or the community planning to add some OOP
> characteristics
> to the interpreter in the near future?
>
> Here's my suggestion of requirements for the first EuOOP release:
With the exception of the static classes and private members, ooeu can do
everything you're asking about. I think the private members could be
implemented fairly easily, they just haven't been at the top of the list
of things to do.
ooeu url:
http://ooeu.sourceforge.net
> -- I think that there shouldn't be more than one constructor,
> -- since using the superb variable type sequence does the trick
> -- where you would code multiple constructors in traditional
> -- programming languages.
> -- constructor should always be optional(?) and procedure
ooeu allows as many constructors as you like, as long as the signature of
the routines (i.e., the parameters) are different. You're right, that
it's not strictly necessary, but it can make code cleaner in places to
avoid having to construct a sequence (or deconstruct one). Consider:
euclass rect( sequence s )
integer left, top, right, bottom
function rect( integer Left, integer Top, integer Width, integer Height)
return {Left, Top, Width, Height}
end function
function rect( sequence points )
return points
end function
end euclass
OK, so this was super trivial, and the constructors don't really do anything,
but you could see why you might want both constructors.
> -- destructor should always be optional(?) and procedure
> -- destructor should not have any parameters(?)
There is no inherent destructor concept in ooeu. Since objects are really
just normal eu objects, they get garbage collected just like everything
else. If they do something in memory (allocate, or maybe some Win32 or
GTK API or something) then it's the coder's responsibility to make sure
it gets done, presumably through some sort of a destructor that cleans
up after itself.
> procedure SetMyProperty(integer val)
> MyProperty = val
> end procedure
This is possible, but in order to set a property, you have to use the
pass by reference feature of ooeu. Each method (except for constructors)
gets an implicit this variable defined. You can pass 'this' by reference
by putting the asterisk before the method name:
procedure * SetMyProperty( integer val )
this.MyProperty = val
end procedure
> -- Instances could be declared this way...
> MyInstance1 = new MyClass(1.1, {})
> MyInstance2 = new MyClass(1.1, {1, 2, 3})
> -- ...or this way:
> MyInstance1 = instance(routine_id("MyClass"), {1.1, {}})
> MyInstance2 = instance(routine_id("MyClass"), {1.1, {1, 2, 3}})
> -- which way is better, I don't know. Opinions?
ooeu uses the first way, although withoug the 'new':
MyClass MyInstance1, MyInstance2
MyInstance1 = MyClass( 1.1, {} )
MyInstance2 = MyClass( 1.1, {1,2,3} )
The 'new' doesn't really add anything here, since there's no special memory
allocation going on--just a regular eu object allocated in the regular way,
as opposed to a stack vs heap allocation.
> -- To ease the readability and for keeping the similarity to
> -- other programming laguages, I'd really prefer to use dots:
> -- Rob, Is this possible?
> MyInstance1.SetMyProperty(12)
> TempVal = MyInstance1.GetMyProperty()
ooeu uses dot notation. For data members, the dot is really just syntactic
sugar for a subscript operation. For method calls, it basically just adds
the object to the parameter list.
> This should be too hard to code?
Heh, take a look at the source and decide for yourself. :)
> In my opinion, inheriting is a bit over valuated, and to keep it simple
> shouldn't
> be supported in the first release(s) of EuOOP. Or what do you think?
I think that if you don't have inheritance, you've destroyed a big reason
for using OOP: code reuse. It's pretty straightforward in ooeu. When the
class is defined, you specify a datatype. This datatype can be an euphoria
primitive, a user defined type, or another class. If it's another class,
then the object starts out with all the data members and methods of the
previous class. Methods can be overridden if desired. The superclass'
methods can still be utilized using the ooeu casting method (take a look
at the docs for more detail).
> What other OOP stuff people would like to see in Eu?
I have some ideas on how to get virtual functions into ooeu, which will make
it truly oop. Right now it only supports early binding, but will be a lot
more powerful with late binding through virtual functions.
Initially, I was trying to keep the output as compatible with standard
eu as possible (all the oop stuff is really syntactic sugar for normal
euphoria operations). Now that the backend is open source, I'm not so
constrained, since you can get fast operation from ooeu with the c
backend.
Matt
|
Not Categorized, Please Help
|
|
