1. Euphoria Object Oriented Programming
(sorry if you get this twice, I tried to sent this as e-mail to EUForum at
topica.com but it didn't seem to go trough)
Hi,
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:
-- static classes might be nice to have
-- but I don't think that there's a burning need
-- for them since you could have almost the same
-- functionality by declaring instance
-- in the same include file where you have the class
class MyClass [static]
-- scope for variables and constants declared here
-- should be limited inside the class (private)
-- This scope level is really handy for large projects,
-- since you don't need to
integer MyProperty
-- 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
procedure constructor(atom MyAttribute1, sequence MyAdditionalAttributes)
-- do some stuff
MyProperty = 0
end procedure
-- destructor should always be optional(?) and procedure
-- destructor should not have any parameters(?)
procedure destructor()
-- do some stuff
end procedure
procedure SetMyProperty(integer val)
MyProperty = val
end procedure
function GetMyProperty()
return MyProperty
end function
procedure MethodAddToMyProperty(integer val)
MyProperty += val
end procedure
end class
-- main:
atom MyInstance1, MyInstance2
integer TempVal
-- 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?
-- 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()
This should be too hard to code?
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?
What other OOP stuff people would like to see in Eu?
Best regards,
-- Tapani Talvitie
2. Re: Euphoria Object Oriented Programming
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
3. Re: Euphoria Object Oriented Programming
- Posted by Tapani Talvitie <tapani.talvitie at gmail.com>
Jan 01, 2007
-
Last edited Jan 02, 2007
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
4. Re: Euphoria Object Oriented Programming
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Jan 01, 2007
-
Last edited Jan 02, 2007
Tapani Talvitie wrote:
>
> 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?
Not really. I've been slammed at work lately, and my second child was just
born, so even though I've been at home, I haven't had the energy or
concentration to do much coding.
Matt
5. Re: Euphoria Object Oriented Programming
- Posted by cklester <cklester at yahoo.com>
Jan 01, 2007
-
Last edited Jan 02, 2007
Matt Lewis wrote:
>
> Not really. I've been slammed at work lately, and my second child was just
> born, so even though I've been at home, I haven't had the energy or
> concentration to do much coding.
Matt, don't be lazy. :D JK!!!
Congrats on the brand spankin' new kiddo!! Where's the baby photo album? :)
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
6. Re: Euphoria Object Oriented Programming
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 01, 2007
-
Last edited Jan 02, 2007
Yes, Matt, congratulations!
Oh, and I know I've mentioned before that I would rather see some kind of
prototype-based OO instead of class-based. But I'm not very good at large
projects that's why I can't do it myself.
I just think that it would fit better with Euphoria's paradigm and I find it
more interesting than class-based OO.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
7. Euphoria Object Oriented Programming
- Posted by Tapani <tapani.talvitie at gmail.com>
Jan 01, 2007
-
Last edited Jan 02, 2007
Hi,
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:
-- static classes might be nice to have
-- but I don't think that there's a burning need
-- for them since you could have almost the same
-- functionality by declaring instance
-- in the same include file where you have the class
class MyClass [static]
-- scope for variables and constants declared here
-- should be limited inside the class (private)
-- This scope level is really handy for large projects,
-- since you don't need to
integer MyProperty
-- 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
procedure constructor(atom MyAttribute1, sequence
MyAdditionalAttributes)
-- do some stuff
MyProperty = 0
end procedure
-- destructor should always be optional(?) and procedure
-- destructor should not have any parameters(?)
procedure destructor()
-- do some stuff
end procedure
procedure SetMyProperty(integer val)
MyProperty = val
end procedure
function GetMyProperty()
return MyProperty
end function
procedure MethodAddToMyProperty(integer val)
MyProperty += val
end procedure
end class
-- main:
atom MyInstance1, MyInstance2
integer TempVal
-- 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?
-- 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()
This should be too hard to code?
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?
What other OOP stuff people would like to see in Eu?
Best regards,
-- Tapani Talvitie
8. Re: Euphoria Object Oriented Programming
Tapani Talvitie wrote:
> 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.
I would not want to add OOP to Euphoria.
I think Euphoria should try to remain simple
and accessible to beginners and hobbyists.
OOP seems to be mainly beneficial in very large
programs developed by multiple professional programmers.
We already have some add-on OOP libraries for Euphoria,
such as Mike Nelson's Method Euphoria.
However, if a clear majority of Euphoria programmers
wanted it, and someone was prepared to do it, I would
not try to veto it. (I've recently seen what can happen
to dictators).
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
9. Re: Euphoria Object Oriented Programming
Robert Craig wrote:
> However, if a clear majority of Euphoria programmers
> wanted it, and someone was prepared to do it, I would
> not try to veto it. (I've recently seen what can happen
> to dictators).
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Heh. Well, they haven't tried to hang Linus Torvalds, yet :) !
In general principles, I vote against it, except for what I've said with regards
to prototype-based OOP. There are other improvements that should be made to
Euphoria besides OOP that are higher priority, IMO, yet still with the goal of
keeping it simple.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
10. Re: Euphoria Object Oriented Programming
Robert Craig wrote:
>
> Tapani Talvitie wrote:
> > 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.
>
> I would not want to add OOP to Euphoria.
> I think Euphoria should try to remain simple
> and accessible to beginners and hobbyists.
> OOP seems to be mainly beneficial in very large
> programs developed by multiple professional programmers.
>
> We already have some add-on OOP libraries for Euphoria,
> such as Mike Nelson's Method Euphoria.
>
> However, if a clear majority of Euphoria programmers
> wanted it, and someone was prepared to do it, I would
> not try to veto it. (I've recently seen what can happen
> to dictators).
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
I disagree,
I would like to see OO added to the base Euphoria language.
It can be added in such a way where if you wish NOT to use classes everything
continues as now.
I don't think OO is limited to large multi person team projects.
I think Euphoria should be designed to work well for large as well as small
projects.
OO would also improve the usage of includes and libraries.
(I have no idea?) but maybe it could also improve the namespace problems
being discussed??
Regards,
Ray Smith
http://RaymondSmith.com
11. Re: Euphoria Object Oriented Programming
- Posted by ags <eu at 531pi.co.nz>
Jan 02, 2007
Robert Craig wrote:
> I would not want to add OOP to Euphoria.
> I think Euphoria should try to remain simple
> and accessible to beginners and hobbyists.
I agree with that, but if OO can be added as a superset to the language (ie you
don't have to use it, and it doesn't break anything already there) then it would
be a good thing.
As for *doing* it though... 
Gary
12. Re: Euphoria Object Oriented Programming
Ahoy! Mike Nelson's Magnus OOPus, "Methodica", should
be making its debut sometime soon. I think it would
be wise to wait and see what Mike comes up with before
adding OOP to native Euphoria.
Ken Rhodes
Folding at Home: http://folding.stanford.edu/
100% MicroSoft Free
SuSE Linux 10.0
No AdWare, SpyWare, or Viruses!
Life is Good,
13. Re: Euphoria Object Oriented Programming
If you add OO to Euphoria, people will have to learn it.
Why? Because sooner or later (probably sooner), they will see Euphoria
code that is object-oriented. How would the base libraries look?
Would they be OO or not? If they are, people will have to learn OO programming
to use them. If they aren't, then wouldn't that look kind of ridiculous?
Having an OO language, with base libraries that aren't OO?
Because of this, I think the main distribution of Euphoria shouldn't have
a full object-oriented system. Keep it simple, like it is now. One possibility
would be to develop a separate object-oriented Euphoria distribution.
That way, people can start with the main Euphoria distribution, and later
switch to the OO distribution, IF THEY WANT TO, or they can stay with the main
distribution, or they can use both. Somebody with more experience in other
OO languages (like Java or C#) could start with the OO distribution, or not.
--
The Internet combines the excitement of typing
with the reliability of anonymous hearsay.
tommy online: http://users.telenet.be/tommycarlier
tommy.blog: http://tommycarlier.blogspot.com
14. Re: Euphoria Object Oriented Programming
Tommy Carlier wrote:
>
> If you add OO to Euphoria, people will have to learn it.
> Why? Because sooner or later (probably sooner), they will see Euphoria
> code that is object-oriented. How would the base libraries look?
> Would they be OO or not? If they are, people will have to learn OO programming
> to use them. If they aren't, then wouldn't that look kind of ridiculous?
> Having an OO language, with base libraries that aren't OO?
OO can be added to Euphoria an no one would be forced to use the OO features.
The base libraries (at least initially) can stay exactly as is.
If in the future they are converted to an OO style they could be very easily
used by people who don't use OO. It's very easy to use simple objects without
knowing anything about OO).
And, I imagine the current libraries would always be available for backwards
compatibility.
> Because of this, I think the main distribution of Euphoria shouldn't have
> a full object-oriented system. Keep it simple, like it is now. One possibility
> would be to develop a separate object-oriented Euphoria distribution.
> That way, people can start with the main Euphoria distribution, and later
> switch to the OO distribution, IF THEY WANT TO, or they can stay with the main
> distribution, or they can use both. Somebody with more experience in other
> OO languages (like Java or C#) could start with the OO distribution, or not.
It seems 100% obvious to me ...
"If" OO can be added without forcing anyone to use OO features and only adding
a small size to Eu and a small reduction in speed ... I so go for it.
If this isn't possible (and I don't know?) I'd say it deserves more discussion.
Regards,
Ray Smith
http://RaymondSmith.com
15. Re: Euphoria Object Oriented Programming
Robert Craig wrote:
>
> Tapani Talvitie wrote:
> > 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.
>
> I would not want to add OOP to Euphoria.
> I think Euphoria should try to remain simple
> and accessible to beginners and hobbyists.
> OOP seems to be mainly beneficial in very large
> programs developed by multiple professional programmers.
>
> We already have some add-on OOP libraries for Euphoria,
> such as Mike Nelson's Method Euphoria.
>
> However, if a clear majority of Euphoria programmers
> wanted it, and someone was prepared to do it, I would
> not try to veto it. (I've recently seen what can happen
> to dictators).
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Hi
I agree. I do not think OOP should be added to the base, unless it is completely
transparent, and does not affect the way a lot of people use euphoria.
Which in itself raises an interesting wuestion - how do a lot of people use
euphoria?
Chris
16. Re: Euphoria Object Oriented Programming
Tommy Carlier wrote:
>
> If you add OO to Euphoria, people will have to learn it.
> Why? Because sooner or later (probably sooner), they will see Euphoria
> code that is object-oriented. How would the base libraries look?
> Would they be OO or not? If they are, people will have to learn OO programming
> to use them. If they aren't, then wouldn't that look kind of ridiculous?
> Having an OO language, with base libraries that aren't OO?
>
> Because of this, I think the main distribution of Euphoria shouldn't have
> a full object-oriented system. Keep it simple, like it is now. One possibility
> would be to develop a separate object-oriented Euphoria distribution.
> That way, people can start with the main Euphoria distribution, and later
> switch to the OO distribution, IF THEY WANT TO, or they can stay with the main
> distribution, or they can use both. Somebody with more experience in other
> OO languages (like Java or C#) could start with the OO distribution, or not.
I agree! I left Perl because of it's OOP centricness from Perl4 to Perl5.
Early in the transition, life was not too bad. Then it became increasingly
necessary to learn OOP in order to use the CPAN wealth of modules. Good for
some people - not so good for others.
If a bunch of folks want OOP EU, then I say take the Open Source code and fork
a OOP version -- call it EuphOOria and be done with it. My .02.
--
duke
17. Re: Euphoria Object Oriented Programming
duke normandin wrote:
> If a bunch of folks want OOP EU, then I say take the Open Source code and fork
> a OOP version -- call it EuphOOria and be done with it. My .02.
> --
> duke
Agreed. Keep Eu non-OOP.
18. Re: Euphoria Object Oriented Programming
What everyone is forgetting is that if OOP was added to the Euphoria
( transparent or not, optional or not ) it would make executables
even larger than they all ready are.
The only time it will be practical is when Euphoria becomes a compiler
and unnecessary code is strip out in the final executable.
If Rob had made shrouding work or a user could include il's in 3.0
then the extra overhead would have been strip out.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
19. Re: Euphoria Object Oriented Programming
My 2 cents:
I don't even think OO is good. Reasons: good programming practices favor
high cohesion modules and low coupling between them. Polymorphism and
inheritance do exactly the opposite.
Regards.
20. Re: Euphoria Object Oriented Programming
Bernie Ryan wrote:
>
> What everyone is forgetting is that if OOP was added to the Euphoria
> ( transparent or not, optional or not ) it would make executables
> even larger than they all ready are.
No kidding. ooeu compiles to about 200K larger than stock exw under
Open Watcom. That's the difference between including win32lib or not
including win32lib on a bound executable (when no win32lib routines
are used). To me, personally, this is negligible.
> The only time it will be practical is when Euphoria becomes a compiler
> and unnecessary code is strip out in the final executable.
>
> If Rob had made shrouding work or a user could include il's in 3.0
> then the extra overhead would have been strip out.
You completely lost me here. How is this not practical? What extra
overhead are you talking about here? There is no extra overhead in the
euphoria code, just in the interpreter or the runtime library.
And why are you so concerned about executable size? I find it hard to
believe that 200K would make a big difference unless you're targeting
something embedded, but then maybe eu isn't the right language for that
platform.
I can understand (and to a certain extent agree with) arguments about the
inherent value of OOP, but this doesn't seem to bear any relation to
what we're talking about here.
Matt
21. Re: Euphoria Object Oriented Programming
Ricardo M. Forno wrote:
>
> My 2 cents:
> I don't even think OO is good. Reasons: good programming practices favor
> high cohesion modules and low coupling between them. Polymorphism and
> inheritance do exactly the opposite.
> Regards.
Can you explain a little better? While I'm in the anti-OOP camp right now I
always thought that OOP reduces coupling between modules. I thought that was one
of the points behind it.
Right now with Euphoria to expose an interface you have to do it with global
routines and variables. With OOP you would just create an object and in most
cases you wouldn't even have to worry about inheritance.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
22. Re: Euphoria Object Oriented Programming
Gary wrote:
> I agree with that, but if OO can be added as a superset to the language (ie
> you don't have to use it, and it doesn't break anything already there) then
> it would be a good thing.
Ray Smith wrote:
> I would like to see OO added to the base Euphoria language.
> It can be added in such a way where if you wish NOT to use classes everything
> continues as now.
>
> I don't think OO is limited to large multi person team projects.
>
> I think Euphoria should be designed to work well for large as well as small
> projects.
>
> OO would also improve the usage of includes and libraries.
I agree with Ray and Gary and others, that OO should be superset and Euphoria
coder wouldn't need to learn it. It should be implemented the same way like
multitasking: learn it only if you need it. But yet it should come in the main Eu
distribution so that we would have one standardized OO model that would always
work with the latest release. Knowing that there is continual support for the OO
might encourage people to use it in commercial software. What I’ve learned is
that OO is almost de facto in commercial usage today.
This might, hopefully, attract also more corporations to use Euphoria. And wider
corporate usage would encourage schools and universities to teach the mighty
Euphoria and so on. I believe that a big bunch of users is what Euphoria needs so
that it will stay alive for years to come. Once a critical mass is using the
Euphoria, I believe it has the potential to eventually crush all the shitty
languages like Basic and Java. But we gotta get the big wheel turning ;)
Adding OO to Euphoria shouldn't be a big job, as Matt has proven.
Ray wrote:
> The base libraries (at least initially) can stay exactly as is.
I totally agree with Ray in this. And if someone makes libraries with oop and
you want to use them, you can use them almost the same way that you use namespace
identifiers in the current release of Euphoria.
Ray wrote:
> (I have no idea?) but maybe it could also improve the namespace problems
> being discussed??
I think oop would improve namespace problems a lot. Few years ago I was writing
experimental 3D engine with Euphoria. It got big with 20 include files and in the
end I had namespace problems even though I was coding it alone! 3D world also
reflects the real world and thus classes and instances would not only had made
the code smaller but also a lot more readable and easier to maintain/develop.
Matt wrote:
> my second child was just born
Congratulations man!
Best regards,
--Tapani Talvitie
Best regards,
--Tapani Talvitie
23. Re: Euphoria Object Oriented Programming
ChrisBurch2 wrote:
>
>
> I agree. I do not think OOP should be added to the base, unless it is
> completely
> transparent, and does not affect the way a lot of people use euphoria.
>
> Which in itself raises an interesting wuestion - how do a lot of people use
> euphoria?
As a person who has created an OOP version of Euphoria, I'll admit that I'm
not a huge fan of OOP, although it definitely has some nice features that
I occaisionally like to use.
The main way that I suspect I personally would use ooeu's oo features
is for creating complex data structures. Of course, these end up being
simply sequences. The main value is, admittedly syntactic sugar for
being able to use dot notation and member names that don't pollute the
namespace. This is an issue that has [rightly] come up many times
around here, and I think that the ooeu solution is a pretty good one
that stays true to the Euphoria way of doing things.
You also get other nice things, such as methods that are explicitly tied
to the data. It ends up being a way to organize your code. It's obvious
that certain routines apply to certain types of data. By using inheritance,
you can reuse code fairly easily and in a way that's semi-self documenting.
None of this changes any current euphoria functionality. It's true, of
course, that if you want to use OOP-style code that others have written,
you may need to use some OOP yourself. Alternatively, someone could
simply wrap the OOP with straight eu-style procedural routines, assuming
that you really, really don't want any dots in your code.
Since I'm not a big OOP fan, some may wonder why I wrote ooeu. The short
answer is, because I could. A lot of my projects start out that way.
But also, there's more to ooeu than OOP:
* goto (static and dynamic)
* pass by reference
* find_from()/match_from()
* eval()/embeddable scripting engine
* var_id()/read_var()/write_var()/dump_var()
We talk a lot about features that we'd like to see in eu, and when Rob
put out the eu-in-eu, I thought it would be a great idea to try some of
these things out, to see how they might work. When Rob opened up the
backend, too, it just got even better. I see ooeu less as a fork of eu
than as an alternative testing branch of development.
Matt
24. Re: Euphoria Object Oriented Programming
Why oop? To me it likes reinventing the wheel. There is already many
powerfull oop languages out there.
Personnally I thinks of 3 things to improve my euphoria experience. And those
could be done at the front end and woudn't affect the existing code base.
1) namespaces inside file
[global] namespace MyNameSpace -- a name space could be optionnally global
integer a,b
function fx(integer y)
...
end function
end namespace
now to access objects inside that name space one would write
MyNameSpace:a
MyNameSpace:fx(2)
etc...
2) initialized variables
integer a=1, b=3, c
3) persistant variables inside procedures and functions
procedure proc(integer n)
persist atom a=0,b=0 -- need feature 2 above
a += 10*n
b = n/10
end procedure
those persistents objects would be stored in global space as top level objects
regards,
Jacques Deschênes
25. Re: Euphoria Object Oriented Programming
jacques deschênes wrote:
> 3) persistant variables inside procedures and functions
> procedure proc(integer n)
> persist atom a=0,b=0 -- need feature 2 above
> a += 10*n
> b = n/10
> end procedure
> those persistents objects would be stored in global space as top level objects
>
> regards,
> Jacques Deschênes
I think you can do this with the multitasking. At least I've assumed as much
even though I haven't tried it.
I think Euphoria's multitasking essentially creates closures.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
26. Re: Euphoria Object Oriented Programming
- Posted by Bernie Ryan <xotron at bluefrog.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Matt Lewis wrote:
>
> No kidding. ooeu compiles to about 200K larger than stock exw under
> Open Watcom. That's the difference between including win32lib or not
> including win32lib on a bound executable (when no win32lib routines
> are used). To me, personally, this is negligible.
>
I was talking about binding programs not using the 'C' compiler.
>
> You completely lost me here. How is this not practical? What extra
> overhead are you talking about here? There is no extra overhead in the
> euphoria code, just in the interpreter or the runtime library.
>
When you run shroud for 2.4 it stripped out all the unused functions
and constants.
>
> And why are you so concerned about executable size? I find it hard to
> believe that 200K would make a big difference unless you're targeting
> something embedded, but then maybe eu isn't the right language for that
> platform.
>
Not everyone that uses Euphoria wants and extra 200k that they are
not using.
If I wanted to use OOP I would use I would use C++.
If I want smaller windows programs then I can use MIC's NQA.
>
> I can understand (and to a certain extent agree with) arguments about the
> inherent value of OOP, but this doesn't seem to bear any relation to
> what we're talking about here.
>
> Matt
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
27. Re: Euphoria Object Oriented Programming
- Posted by cchris005 at fastmail.fm
Jan 02, 2007
-
Last edited Jan 03, 2007
> Subject: Euphoria Object Oriented Programming
>
>
>
>
> posted by: Tapani Talvitie <tapani.talvitie at gmail.com>
>
> (sorry if you get this twice, I tried to sent this as e-mail to
> EUForum at topica.com but it didn't seem to go trough)
>
> Hi,
>
> 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:
>
> }}}
<eucode>
> -- static classes might be nice to have
> -- but I don't think that there's a burning need
> -- for them since you could have almost the same
> -- functionality by declaring instance
> -- in the same include file where you have the class
> class MyClass [static]
> -- scope for variables and constants declared here
> -- should be limited inside the class (private)
> -- This scope level is really handy for large projects,
> -- since you don't need to
> integer MyProperty
>=20
> -- 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
> procedure constructor(atom MyAttribute1, sequence
> MyAdditionalAttributes)
> -- do some stuff
> MyProperty = 0
> end procedure
>=20
> -- destructor should always be optional(?) and procedure
> -- destructor should not have any parameters(?)
> procedure destructor()
> -- do some stuff
> end procedure
> procedure SetMyProperty(integer val)
> MyProperty = val
> end procedure
> function GetMyProperty()
> return MyProperty
> end function
> procedure MethodAddToMyProperty(integer val)
> MyProperty += val
> end procedure
> end class
>=20
> -- main:
>=20
> atom MyInstance1, MyInstance2
> integer TempVal
>=20
> -- 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?
>=20
> -- 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()
> </eucode>
{{{
>
> This should be too hard to code?
>
> 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?
>
> What other OOP stuff people would like to see in Eu?
>
>
> Best regards,
> -- Tapani Talvitie
>
Perhaps we need to be more precise about what "private" means:
* in C++, private is *truly* private, and there is a "protected" scope
to declare a member as available to derived classes.
* In Eiffel,members are automatically inherited, but you cn undefine
some.
I prefer the first approach, even though I have been using both.
Inheritance and virtual methods are what make OOP work. They have to be
there.
I can read some posts where people fret about OO concepts making Eu more
complex. Sorry to disagree here:
* Some languages, like Eiffel, express *everything* in terms of classes
and in a OO way. This is clumsy sometimes, as much as it is soooo clumsy
to code object oriented code in native Eu. We don't need to take that
route. An hybrid (=E0 la C++) approach is best there, as it keeps the
original language intact. Split the manual if you are afraid of the
refman growing too much.
* Some sort of code is largely simplified by using OO paradigms.
Typically:
** If you manipulate entities whose details may change unbeknowst to
you, but whose general properties are common (they inherit from a
possibly avstract class), then OO make this *simpler*, not more
complicated.
** If, on the opposite, you deal only with stabdard objects and have a
linear/loop execution model, then a procedural language like Eu is best
suited.
The day OOEu is mature enough, I'll consider it my preferred language
(Eiffel being better for large projects).
CChris
--
=20=20
cchris005 at fastmail.fm
--
http://www.fastmail.fm - Or how I learned to stop worrying and=0D
love email again
28. Re: Euphoria Object Oriented Programming
- Posted by jacques deschênes <desja at globetrotter.net>
Jan 02, 2007
-
Last edited Jan 03, 2007
Hi Jason,
1)It's not about closure but namespaces. Namespaces are very usefull to avoid
naming conflict but also to groups functions and data like in oop except
in a simpler (and limited) way. Obviously the same could be done by creating
a lot of small includes files. But I think it would be usefull to be able
to declare many namespaces inside a single file.
2) How often I do something like that in my coding:
integer a a= 10
sequence test test = "ceci est un exemple"
a lot of typing for nothing
I would appreciate to be able to do.
integer a= 10
sequence test="ceci est un test"
3) I see myself often declaring variables outside procedures (functions) for the
the only usage of a single procedure (function) to keep persistant state between
call. I don't think such variables should be declared at top level.
I won't talk about closure here, although I read about it in wikipedia I don't
grasp the concept completely.
regards,
Jacques Deschênes
Jason Gade wrote:
>
> jacques deschênes wrote:
> > 3) persistant variables inside procedures and functions
> > procedure proc(integer n)
> > persist atom a=0,b=0 -- need feature 2 above
> > a += 10*n
> > b = n/10
> > end procedure
> > those persistents objects would be stored in global space as top level
> > objects
> >
> > regards,
> > Jacques Deschênes
>
> I think you can do this with the multitasking. At least I've assumed as much
> even though I haven't tried it.
>
> I think Euphoria's multitasking essentially creates closures.
> --
> "Any programming problem can be solved by adding a level of indirection."
> --anonymous
> "Any performance problem can be solved by removing a level of indirection."
> --M. Haertel
> "Premature optimization is the root of all evil in programming."
> --C.A.R. Hoare
> j.
29. Re: Euphoria Object Oriented Programming
- Posted by Matt Lewis <matthewwalkerlewis at gmail.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Bernie Ryan wrote:
>
> Matt Lewis wrote:
> >
> > No kidding. ooeu compiles to about 200K larger than stock exw under
> > Open Watcom. That's the difference between including win32lib or not
> > including win32lib on a bound executable (when no win32lib routines
> > are used). To me, personally, this is negligible.
> >
>
> I was talking about binding programs not using the 'C' compiler.
I know. So was I. I looked at the difference in interpreter size (exw
vs ooeu) and then bound a trivial program with and without including
win32lib and compared the results.
> When you run shroud for 2.4 it stripped out all the unused functions
> and constants.
Not exactly (though 3.0 does the same thing). It stripped out what it
could prove wasn't used. As the win32lib example shows, even though I
simply included win32lib and didn't call anything, the initialization,
etc forced 200K worth of stuff to be added to the *bound* executable.
> Not everyone that uses Euphoria wants and extra 200k that they are
> not using.
So I'll ask again, why not? How does that extra 200K matter? You're
using this argument to justify a course of action, and so far, your
argument is equivalent to "Because I said so."
If we were talking about 20MB (like, say, the .Net runtime) then I might
agree with you that you had a point without going further. But it's
a whole lot smaller than that. Please explain the situation where 200K
extra in an executable is a real problem.
> If I wanted to use OOP I would use I would use C++.
So what? By this argument, no feature should ever be added to Euphoria
if it exists in another language. I'm not arguing that everything ever
imagined should be in Euphoria, but again, you haven't made a good
argument for excluding OOP from Euphoria.
Matt
30. Re: Euphoria Object Oriented Programming
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Yeah, and I may have meant "continuation" anyway. I get those two confused even
though I think they are related.
It's kind of like object-orientation. Lisp and Scheme have closures and
continuations. If I understand correctly, they are the entire basis for
Javascript's object-orientation.
The main thing is that it gives you your "persistent" variables but yeah, there
are some hoops to jump through.
I see if I can come up with an example.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
31. Re: Euphoria Object Oriented Programming
- Posted by Jason Gade <jaygade at yahoo.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Never mind-- tasks have to be procedures, not functions. They can't return any
results except through a top level variable.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
32. Re: Euphoria Object Oriented Programming
- Posted by don cole <doncole at pacbell.net>
Jan 02, 2007
-
Last edited Jan 03, 2007
Matt Lewis wrote:
>
> Bernie Ryan wrote:
> >
> > Matt Lewis wrote:
> > >
> > > No kidding. ooeu compiles to about 200K larger than stock exw under
> > > Open Watcom. That's the difference between including win32lib or not
> > > including win32lib on a bound executable (when no win32lib routines
> > > are used). To me, personally, this is negligible.
> > >
> >
> > I was talking about binding programs not using the 'C' compiler.
>
> I know. So was I. I looked at the difference in interpreter size (exw
> vs ooeu) and then bound a trivial program with and without including
> win32lib and compared the results.
>
> > When you run shroud for 2.4 it stripped out all the unused functions
> > and constants.
>
> Not exactly (though 3.0 does the same thing).
I'm glad you said that because I was about to aski that question. I have not
upgr4aded to 3.0 as of yet.
>It stripped out what it
> could prove wasn't used. As the win32lib example shows, even though I
> simply included win32lib and didn't call anything, the initialization,
> etc forced 200K worth of stuff to be added to the *bound* executable.
>
> > Not everyone that uses Euphoria wants and extra 200k that they are
> > not using.
>
> So I'll ask again, why not? How does that extra 200K matter?
I agree.
>You're
> using this argument to justify a course of action, and so far, your
> argument is equivalent to "Because I said so."
>
> If we were talking about 20MB (like, say, the .Net runtime) then I might
> agree with you that you had a point without going further. But it's
> a whole lot smaller than that. Please explain the situation where 200K
> extra in an executable is a real problem.
>
> > If I wanted to use OOP I would use I would use C++.
>
> So what? By this argument, no feature should ever be added to Euphoria
> if it exists in another language. I'm not arguing that everything ever
> imagined should be in Euphoria, but again, you haven't made a good
> argument for excluding OOP from Euphoria.
>
> Matt
Don Cole
33. Re: Euphoria Object Oriented Programming
- Posted by Vincent <darkvincentdude at yahoo.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Why does Euphoria need OO features? Mike Nelson already offers robust OOP
solutions in library form.
There are hundreds of languages that offer OO. Why does Euphoria need to become
yet another? Adding OO to the language definition certainly won't simplify
anything.
Perhaps this is the point where Euphoria splits into two entities? One in which
is supportive of OOP concepts and another that retains it's founding principles
of simplicity and performance?
I'm not really complaining though. I found something far better than any general
purpose language could offer me. A platform that doesn't involve coding or
programming languages, only simple mouse clicks and keystrokes.
Regards,
Vincent
34. Re: Euphoria Object Oriented Programming
- Posted by cklester <cklester at yahoo.com>
Jan 02, 2007
-
Last edited Jan 03, 2007
Vincent wrote:
>
> I'm not really complaining though. I found something far better than any
> general
> purpose language could offer me. A platform that doesn't involve coding or
> programming
> languages, only simple mouse clicks and keystrokes.
Do tell...
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
35. Re: Euphoria Object Oriented Programming
Jason Gade wrote:
>
> Ricardo M. Forno wrote:
> >
> > My 2 cents:
> > I don't even think OO is good. Reasons: good programming practices favor
> > high cohesion modules and low coupling between them. Polymorphism and
> > inheritance do exactly the opposite.
> > Regards.
>
> Can you explain a little better? While I'm in the anti-OOP camp right now I
> always thought that OOP reduces coupling between modules. I thought that was
> one of the points behind it.
>
> Right now with Euphoria to expose an interface you have to do it with global
> routines and variables. With OOP you would just create an object and in most
> cases you wouldn't even have to worry about inheritance.
>
It is hard to explain it in detail. However:
Inheritance: If class B inherits from class A, then the behavior of a class B
object depends not only on the definition of class B but also class A. So,
obviously classes A and B are highly coupled.
Polymorphism: A method doesn't do a single task, but many, according to the
types of object to what it applies (low coherence).
Moreover, classes mix data and procedures. They are in totally different
fields.
I think that OOP will eventually fail as hierachical databases did, in
favor of relational databases, for the same reason. In relational databases,
each piece of data is not related to others, but the relation is provided
in a flexible way by procedures (SQL and PL/SQL sentences), as old good
structured programming does.
You can get more criticism of OOP in places like this one:
http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/
Regards.
36. Re: Euphoria Object Oriented Programming
Ricardo M. Forno wrote:
> It is hard to explain it in detail. However:
>
> Inheritance: If class B inherits from class A, then the behavior of a class
> B
> object depends not only on the definition of class B but also class A. So,
> obviously classes A and B are highly coupled.
I can see that. But when you use objects that you don't have to extend then
you've just got an interface, right? So if you have a mix of objects that you do
and don't have to extend isn't that better than the procedural approach in some
cases? Where the OO approach can be more loosely coupled in the cases where you
don't have to extend classes you are re-using yet in the procedural approach you
have to couple pretty tightly regardless.
Again, that's why I like prototype-based OO better than class-based OO.
>
> Polymorphism: A method doesn't do a single task, but many, according to the
> types of object to what it applies (low coherence).
I see some polymorphism in Euphoria already. Maybe we should be talking about
genericity rather than polymorphism, though. I like the idea of generic routines
that behave the same or similarly on different datatypes.
But I understand what you mean I think.
> Moreover, classes mix data and procedures. They are in totally different
> fields.
>
That's kind of the thing I like about it though. I usually think about it more
in terms of "API" and "state", though. I agree that it can be overdone.
> I think that OOP will eventually fail as hierachical databases did, in
> favor of relational databases, for the same reason. In relational databases,
> each piece of data is not related to others, but the relation is provided
> in a flexible way by procedures (SQL and PL/SQL sentences), as old good
> structured programming does.
>
> You can get more criticism of OOP in places like this one:
>
> <a
> href="http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/">http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/</a>
>
> Regards.
I'll try to read that tomorrow. Thanks for sharing, I'm always interested in
learning new things.
I remember it took me a very long time to understand exactly what OO is.
Surveying programming languages I can see where multi-paradigm languages are
better than one-trick ponies. I don't think that OO is useless but I also don't
think it is the solution to all programming problems. Sometimes you just want to
tell the computer to do something -- imperative, rather than trying to think of
how different objects fit together.
However sometimes having an object makes sense, especially when it is something
that has to keep state as well as provide an interface to change that state.
--
"Any programming problem can be solved by adding a level of indirection."
--anonymous
"Any performance problem can be solved by removing a level of indirection."
--M. Haertel
"Premature optimization is the root of all evil in programming."
--C.A.R. Hoare
j.
37. Re: Euphoria Object Oriented Programming
Ricardo M. Forno wrote:
> You can get more criticism of OOP in places like this one:
>
> <a
> href="http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/">http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/</a>
Thanks for the link.
Despite being a never-really-got-oop kinda guy, I was looking at Tapani's
post and thinking "hmm, maybe"... but reading some of these links reminded
me that what I had just seen was *NOT OOP*.
We must not put OOP into Eu, ever.
We do not want (multiple) inheritance, polymorphism, encapsulation, scalar,
overloading, prototyping, instance, attribute, constructor, destructor,
method and who knows what else to become part of "Eu-speak".
========================================================================
I'm all for, and very interested, if someone writes "here is a (working)
program that would have been SO much easier if I could have written THIS!"
========================================================================
But PLEASE let's not call it OOP, even if some of it bears remarkable
similarity to features found in other languages.
Borrow/steal the best bits by all means, but don't call it OOP.
So I say scope not class, procedure or function not method, etc.
(hmm, I guess that is pretty much the sort of theoretical statement that
I doubt will get us anywhere, whereas well-thought-out examples, along
with the query "does this look nice?" might, possibly...)
And to the question is it OOP? I say plan to reply: "No. Absolutely not.
It takes the best bits and avoids those that made people hate OOP. You
can write huge programs without ever knowing anything about OOP. If you
are already an oop-head, you should get by, miss a few things, and take
a while to re-learn how to code properly." 
Lastly, I think we should all promise to point fingers and laugh at anyone
who says "we should have this because it is in C++".
Regards,
Pete
PS regarding Matt not using new, shouldn't it always from the get-go (ie
[pre] C++) have been x = Myclass.new(blah) anyway? <shrug>
39. Re: Euphoria Object Oriented Programming
Vincent wrote:
> It's called Limnor.
That looks scary.
I'd say you're a braver man than I taking on a programming...
uh... program... that requires all that .NET stuff, only runs on Windows,
and actually costs money.
Good luck with it! :D
-=ck
"Programming in a state of Euphoria."
http://www.cklester.com/euphoria/
40. Re: Euphoria Object Oriented Programming
cklester wrote:
> That looks scary.
Whats scary is how quick anyone can rip out an app with this thing. Perhaps this
is the future of software development as we know it? Over fifty awards can't be
wrong.
It's not yet able to do much in the way of web applications ran inside a
browser. That functionality is coming in the future. But there is a program
called Tersus that specializes in web application development through a
non-coding approach. It happens to be open-source under the GPLv2 license.
> I'd say you're a braver man than I taking on a programming...
> uh... program... that requires all that .NET stuff, only runs on Windows,
> and actually costs money.
Well a native Linux version is feasible if Mono were used. Perhaps this might
occur someday, who knows. But for now, Limnor runs just fine under Linux/Unix
using any virtualization option and the Windows installation disc that comes with
your computer.
As for it costing money... well... only if I plan to start selling my apps and
don't want that pesky nag screen popping up. Then again, that $199 for the full
deal is a one time payment; all consecutive upgrades are free.
> Good luck with it! :D
I know you're being sarcastic but I'll play along.
I think at the end of the day we just desire what fits our needs best.
Regards,
Vincent
41. Re: Euphoria Object Oriented Programming
Pete Lomax wrote:
>
> Ricardo M. Forno wrote:
> > You can get more criticism of OOP in places like this one:
> >
> > <a
> > href="http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/">http://dmoz.org/Computers/Programming/Methodologies/Object-Oriented/Criticism/</a>
>
> Thanks for the link.
>
> Despite being a never-really-got-oop kinda guy, I was looking at Tapani's
> post and thinking "hmm, maybe"... but reading some of these links reminded
> me that what I had just seen was *NOT OOP*.
>
> We must not put OOP into Eu, ever.
Why?
>
> We do not want (multiple) inheritance, polymorphism, encapsulation, scalar,
> overloading, prototyping, instance, attribute, constructor, destructor,
> method and who knows what else to become part of "Eu-speak".
>
Please explain the issue. As I stated before, splitting the refman is enough
to take care of this.
> ========================================================================
> I'm all for, and very interested, if someone writes "here is a (working)
> program that would have been SO much easier if I could have written THIS!"
> ========================================================================
>
Please read my post on this, from yesterday. It's simplistic, of course.
> But PLEASE let's not call it OOP, even if some of it bears remarkable
> similarity to features found in other languages.
>
> Borrow/steal the best bits by all means, but don't call it OOP.
>
> So I say scope not class, procedure or function not method, etc.
> (hmm, I guess that is pretty much the sort of theoretical statement that
> I doubt will get us anywhere, whereas well-thought-out examples, along
> with the query "does this look nice?" might, possibly...)
>
Matt wrote a few posts about it this month as he was replying to Tapani.
Could you comment on his posted code examples, instead of this
unargumented ranting?
> And to the question is it OOP? I say plan to reply: "No. Absolutely not.
> It takes the best bits and avoids those that made people hate OOP. You
> can write huge programs without ever knowing anything about OOP. If you
> are already an oop-head, you should get by, miss a few things, and take
> a while to re-learn how to code properly."
>
> Lastly, I think we should all promise to point fingers and laugh at anyone
> who says "we should have this because it is in C++".
>
You completely lost me there. I don't understand what the issue is.
> Regards,
> Pete
> PS regarding Matt not using new, shouldn't it always from the get-go (ie
> [pre] C++) have been x = Myclass.new(blah) anyway? <shrug>
If x has type Myclass, it looks to me completely straightforward that
"x=new(blah)" invokes Myclass.new(blah) to create an instance of Myclass
and bind it to the identifier "x". Overriding is syntactically ok, though
perhaps not very often useful. Anyway, Myclass x(blah) says the same more
concisely and, as a result, is easier to read and understand.
Puzzled.
CChris
42. Re: Euphoria Object Oriented Programming
Pete Lomax wrote:
>
> PS regarding Matt not using new, shouldn't it always from the get-go (ie
> [pre] C++) have been x = Myclass.new(blah) anyway? <shrug>
I don't think so. The 'new' keyword just tells the compiler to create the
object on the heap instead of the stack, and so must be explicitly freed.
The same constructor is called as if you simply did:
Myclass x(blah);
It's basically (to bastardize C and C++):
Myclass *x = malloc( sizeof(Myclass) );
x->Myclass(blah);
We don't really have this issue in Euphoria, since all of our memory
management issues are taken care of for us (for normal Euphoria objects).
the closest equivalent would be a private variable inside a routine vs
a local or global variable that would hand around until you assigned
something else to it and dereferenced the existing data.
Matt
43. Re: Euphoria Object Oriented Programming
CChris wrote:
[snip]
> If x has type Myclass, it looks to me completely straightforward that
> "x=new(blah)" invokes Myclass.new(blah) to create an instance of Myclass
> and bind it to the identifier "x". Overriding is syntactically ok, though
> perhaps not very often useful. Anyway, Myclass x(blah) says the same more
> concisely and, as a result, is easier to read and understand.
>
> Puzzled.
> CChris
My point to this debate is that if YOU want to program a-la-OOP -- go for it!
Don't be forcing it down my throat!! Like I said in a previous post, Euphoria is
now open source, so put together a Core Development Team and spawm/fork a new OOP
language. Simple as that! I can even give you a name for this new language of
yours -- EuphOOria . Or maybe simply -- Joy. Whatever. I wish all the best in
2007 with this new project. ;)
--
duke
http://www.rootshell.be/~perlster/euphoria/
44. Re: Euphoria Object Oriented Programming
Pete Lomax wrote:
> Despite being a never-really-got-oop kinda guy, I was looking at Tapani's
> post and thinking "hmm, maybe"... but reading some of these links reminded
> me that what I had just seen was *NOT OOP*.
Hi Pete! What's up? Nice to see that you're too still reading Euforum (I've been
out for a while). I checked Edita out and saw that last release was in 2005. Are
you still working on it? It's really a great editor :) I just miss a few key
shortcuts to it and then I'd say it's perfect.
Here's a simple Euphoria style program I wrote to demonstrate what I was
thinking with oo. The demo has class, constructor, destructor and instances.
Could somebody demonstrate an easier way to do this with current Euphoria? Or
even with the suggested namespaces?
include get.e
class Location
-- scope for variables declared here is private (by default)
-- and thus we do not need to write "private" prefix.
-- This way the scope also fits to the nature of other
-- scopes in Euphoria and is quite easy to understand
sequence coords
-- constructor should be named with reserved word constructor
-- why? cause 1) if constructor was named "Location" you would
-- need to change it too if you rename the class. 2) it's
-- easier to understand it's function 3) it's easier to
-- find it if you are reading big class and forgot the
-- exact class name 4) destructor named ~Location would
-- be even more shitty
procedure constructor(sequence InitialCoords)
coords = repeat(0, 3)
-- I think we don't need "this." prefix here
-- since it is obvious that we are
-- referring to the class we're in:
SetCoordinates(InitialCoords)
end procedure
procedure destructor()
-- Here we might close opened files or something else
-- like that. destructor is not needed in this demo
end procedure
procedure SetCoordinates(sequence MyCoords)
if length(MyCoords)!=3 then abort(1) end if
for a = 1 to 3 do
if sequence(MyCoords[a]) then abort(1) end if
coords[a] = MyCoords[a]
end for
end procedure
function GetCoordinates()
return coords
end function
procedure MoveSouth(atom units)
-- Here we distract units from y-axis (north-south):
coords[2] -= units
end procedure
end class
--main
atom MyHome, MyJob, MyCar
MyHome = Location({2, 5, 3})
MyJob = Location({2, 5, 8})
MyCar = Location({2, 5, 12})
while wait_key() do
MyCar.MoveSouth(1)
if equal(MyHome.GetCoordinates, MyCar.GetCoordinates) then
puts(1, "I'm at home!")
elsif equal(MyJob.GetCoordinates, MyCar.GetCoordinates) then
puts(1, "I'm at job!")
end if
end while
if wait_key() then end if
Believe me, I'm not an oo fan. I always rely on functions and procedures when it
makes the code shorter and easier to understand. But in some cases like in the
demo above, oo beats the bells.
Inheritance is the more advanced side of oo but it's been quite poorly
implemented to the other languages. That's why coders find it hard to use and
understand. Maybe we could design an easier syntax? Or is the inheritance really
so complex concept that it can't be presented in simple way? If it is then we
should consider not implementing it.
Please, comment :)
Best regards,
--Tapani Talvitie
45. Re: Euphoria Object Oriented Programming
CChris wrote:
> Why?
> Please explain the issue.
> Please read my post on this, from yesterday.
I did. It was one of the more jargon-filled posts in this thread.
> Matt wrote a few posts about it this month as he was replying to Tapani.
> Could you comment on his posted code examples,
I have no real problem with that, then again as Matt implied, it was not
really a great example. Personally I'd prefer multiple constructors to
be replaced with optional parameters, eg:
procedure new(object s1, integer s2=0, s3=0, s4=0)
if sequence(s1) then s4=s1[4] s3=s1[3] s2=s1[2] s1=s1[1] end if
...
end procedure
so new({1,2,3,4}) and new(1,2,3,4) work the same and avoid any code duplication
whatsoever.
I agree with and like the fact there is no destructor in ooeu.
Putting a * for pass by reference needs some thought. If you are going to
have an implicit "this", why not just always pass it by reference?
> instead of this unargumented ranting?
As I admitted then and will for this post too.
> If x has type Myclass, it looks to me completely straightforward that
> "x=new(blah)" invokes Myclass.new(blah) to create an instance of Myclass
> and bind it to the identifier "x".
Matt said there was no real distinction in Eu since we have automatic memory
management, which is fine by me.
I suspect your use of "bind" there is a bit of C++-speak that we really should
avoid in Eu-speak as of course bind has a rather different meaning!
Regards,
Pete
46. Re: Euphoria Object Oriented Programming
Pete Lomax wrote:
>
> CChris wrote:
>
> > Matt wrote a few posts about it this month as he was replying to Tapani.
> > Could you comment on his posted code examples,
>
> I have no real problem with that, then again as Matt implied, it was not
> really a great example. Personally I'd prefer multiple constructors to
> be replaced with optional parameters, eg:
> }}}
<eucode>
> procedure new(object s1, integer s2=0, s3=0, s4=0)
> if sequence(s1) then s4=s1[4] s3=s1[3] s2=s1[2] s1=s1[1] end if
> ...
> end procedure
> </eucode>
{{{
> so new({1,2,3,4}) and new(1,2,3,4) work the same and avoid any code
> duplication
> whatsoever.
> I agree with and like the fact there is no destructor in ooeu.
> Putting a * for pass by reference needs some thought. If you are going to
> have an implicit "this", why not just always pass it by reference?
I think a lot of this goes to the origin of ooeu. I started with the
eu.ex version that Rob released, and my hope was to be able to generate
IL code that could be run by the RDS backend, so I could only do things
that didn't need alterations to the backend. Since Rob didn't like the
idea of allowing this, I changed course to preprocess ooeu code into
RDS eu code (where feasible).
Pass by reference definitely requires backend modifications. It had
never really occurred to me to make pbr the default on method calls,
although it definitely makes a lot of sense. The only problem is that
it varies from the Euphoria norm, which is, I guess, why I required it
to be explicit.
I think that default parameters could have been done, although it would
have made it more difficult to match routine signatures.
Matt
I've only used the system for a few days, yet managed to create a traditional "Hello World" program with buttons and a real DVD movie player.
Check my apps out. Limnor isn't necessary to run the EXEs: http://channel9.msdn.com/ShowPost.aspx?PostID=269583 http://channel9.msdn.com/ShowPost.aspx?PostID=268353 There is a nag screen unfortuantly. I'm using the trial version that nags but is full-featured and free of any time limitations. I guess thats fair though.
