1. Classes: A small proposal
Here's a wish list for item for Robert: classes for Euphoria.=20
I think that the following syntax is fairly modest. I give examples of =
what a pre-processor could turn it into to make it acceptable to the =
current Euphoria compiler. You can still use Euphoria without any of the =
classes, and it shouldn't break existing code.
[Defining a Class and Attributes]
The following declares a class 'point' with 'base' as it's superclass:
class point inherits base
You could declare attributes with:
point attribute x, y
which would be internally:
global constant point:x =3D 1, point:y =3D 2
The indexes would start at different points if the superclass had =
defined some attributes. I also used ':' here instead of '_' to make the =
code more readable.=20
Notice I cheat and don't implement type checking on the attributes. If =
this were really part of Euphoria, I'd expect something along the lines =
of:
point attribute
integer x,
integer y
But I'm thinking along the lines of quick & dirty, so we'll quickly move =
along to...
[Creating Objects]
Creation of an object would look the same as any other type:
point fred, sam
which could be internally:
sequence fred, sam
[Defining Class Methods]
Routines could be declared as follows:
point function func( integer x )
self.x =3D x
end function
While the internal declaration might actually be:
function point:func( sequence self, integer x )
self[point:x] =3D x
return self
end function
Procedures would be similar.
[Calling Class Methods]
Here's an explicit call to a class function - very atypical:
bar =3D point:func( foo, x )
If the 'point' were left off, the interpreter would assume that the =
function was a 'base' class function.
A more typical call to a class function would look like:
foo.func(x)
Euphoria would first check to see if there were a 'point:func' defined. =
If it did not exist, it would then check the superclass ('base:func'), =
on down the line, until the base class was reached. So you might get:
=20
foo =3D point:func( foo, x )
if the function was defined in the class 'point', or
foo =3D base:func( foo, x )
if the function was defined in the class 'base', or
function 'func' is undefined
if the function is undefined altogether.
Procedures would also be the same:
foo.show()
could be interpreted as:
point:show( foo )
=20
[Summary]
That's all there is to it! For a few modest changes, you get classes, =
objects, attributes AND single level inheritance. Pre-existing code goes =
happily along without breaking. And it converts to 'normal' Euphoria =
code - so it could be implemented by adding a pre-processor onto =
Euphoria.
Comments?
-- David Cuny
2. Re: Classes: A small proposal
Dit is een meerdelig bericht in MIME-indeling.
------=_NextPart_000_0096_01BD8D8E.A0A0B100
charset="iso-8859-1"
>Here's a wish list for item for Robert: classes for Euphoria.
PreProccesing ?? That is not needed at all.
Look at the attached package. It is what I am using for NGL.
It contains a lib for oo programming.
Maintaining the same safety as Euphoria does. (you can specify a routine id
to check the type of an attribute)
The same readability.
The same consistent.
Take a look, change a few routine names to make it more logical. (i just
choose the first name that popped in my head.. i'm not a walking
dictionnairy as it comes to OOP)
Robert, Do I need to sent you this file to get it on the Contribution's
Section or can you just as easily grap it out of this mail ?
Ralf Nieuwenhuijsen,
nieuwen at xs4all.nl
------=_NextPart_000_0096_01BD8D8E.A0A0B100
name="Oop.zip"
3. Re: Classes: A small proposal
Ralf wrote:
>>PreProccesing ?? That is not needed at all.
I agree. I only meant the pre-processing to be an explanation by way of =
analogy. I certainly wouldn't expect it to actually *implemented* like =
that - not by Robert, anyway.
I don't really expect Robert to latch onto the dot notation [i.e.: =
object.function()], because it's just "syntactic sugar" - it's =
essentially a different way of writing something, without adding any new =
functionality. But OOP seems like something that would be a good thing =
to add native to Euphoria, now that Robert's gearing up to code another =
major version.
>>Look at the attached package.
Nice code - even documentation! 
By my count, that makes four contributions for Euphoria OOP extentions:
1. Francis Bussiere's (from *way* back when)
2. Irv's (in Windoz)
3. My own (in WinMan)=20
4. Yours [Ralf's].=20
Did I miss anyone?
Everyone but me seems to use type checking on their OOP attributes. I =
guess I'll cave and add some to my package, too.
> It is what I am using for NGL.
I can hardly wait. Your prior blurb looked very interesting. Will it =
support VGA as well?
[Dot Notation]
I personally think the dot notation:
s.append( "hi there" )
s.slice(1,End-1)
for:
s =3D append( s, "hi there" )
s =3D s[1..length(s)-1]
is cool even without it being OOP. I liked it so much, I went ahead and =
wrote a pre-processor. It's called Dot, and is on the Euphoria Web page. =
The latest version (sent in this morning) can be used in EE in place of =
PP - not that I expect anyone to really latch onto it.
As I mentioned, it's not OOP - but you can certainly combine it with an =
OOP package.
-- David Cuny
4. Re: Classes: A small proposal
>At 06:53 PM 6/1/98 +0200, Ralf wrote:
>
>Dit is een meerdelig bericht in MIME-indeling.
>
>Here's a wish list for item for Robert: classes for Euphoria.
>
>PreProccesing ?? That is not needed at all.
>Look at the attached package. It is what I am using for NGL
>
>It contains a lib for oo programming.
>Maintaining the same safety as Euphoria does. (you can specify a >outine id
>to check the type of an attribute)
>The same readability.
>The same consistent.
>Take a look, change a few routine names to make it more logical. (i just
>choose the first name that popped in my head.. i'm not a walking
>dictionnairy as it comes to OOP)
>
This is interesting stuff - If anyone had trouble decoding
the base64, I have posted it on my web page in readable
form. http://www.mindspring.com/~mountains/OOP.HTM
Regards,
Irv
5. Re: Classes: A small proposal
At 06:53 PM 6/1/98 +0200, Ralf wrote:
>
>Dit is een meerdelig bericht in MIME-indeling.
>
>>Here's a wish list for item for Robert: classes for Euphoria.
>
>PreProccesing ?? That is not needed at all.
>Look at the attached package. It is what I am using for NGL.
>
>It contains a lib for oo programming.
>Maintaining the same safety as Euphoria does. (you can specify a routine id
>to check the type of an attribute)
>The same readability.
>The same consistent.
>Take a look, change a few routine names to make it more logical. (i just
>choose the first name that popped in my head.. i'm not a walking
>dictionnairy as it comes to OOP)
>
This is interesting stuff - If anyone had trouble decoding
the base64, I have posted it on my web page in readable
form. http://www.mindspring.com/~mountains/OOP.HTM
Regards,
Irv
6. Re: Classes: A small proposal
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Jun 01, 1998
-
Last edited Jun 02, 1998
>I don't really expect Robert to latch onto the dot notation [i.e.:
object.function()], because it's just "syntactic sugar" - it's essentially a
different way of writing something, without adding any new functionality.
But OOP seems like something that would be a good thing to add native to
Euphoria, now that Robert's gearing up to code another major version.
Well I dunno, the fact is, you can't emulate Euphoria in any OOP language,
but you can do the other way around. Like you said before also, it should
live in harmony with normal euphoria code. Be like an extension.
I still believe in the ultimate preproccesing language through. Which is
based upon context. I dunno, it stills sounds a bit radical. It sounds like
most of my suggestions for Euphoria I made in the beginning.
(integer/sequence/atom/etc. is just a choice of interpretation of some data,
why not make the choice ourselves.. was one of my ideas.. more than
logically it wasn't followed )
But about OO native to Euphoria or by use of a lib or preproccesor (you
could built something like that inside EE).
All our OOP implementations can only inherit from one other class.
Lets keep it that way. Multiple inheritmens make spagetti code, I can not
understand why this is included in oo. It's such a hack (i know.. the word
'hack' is my new tick) to make up for the restrictions.
>Nice code - even documentation!
Oops, I forgot a few routines..
These are also included:
boolean = compare_class (classx, classy)
Returns -1 if classy was possibly based upon classx, 0 is they are different
or equal, 1 if classx was possible inhereted by classy.
It is not about the values inside the object. Compared are the function
pointers for type checking of each attribute.
'Possibly' because it only means that all attributes types of one class are
all also at the same place in the other class. (the other class only has new
attributes added to them)
If they are equal or different a zero is returned.
boolean = equal_class (classx, classy)
Tells you if they are equal or not. Not their values, but the function
pointers of the attributes, the attribute types thus.
Thus if you want to know if they can be related in a way:
if compare_class (classx, classy) or equal_class (classx, classy) then
-- They are either related
end if
You can also restore the values in an class.
classx = restore_class (classx, superclass)
This only works if classx is related and equal or more than superclass.
It will copy the values in superclass to classx, only for those attributes
they have in common. (so only the new added attributes at the end are
copied, because there will be no copying when they do not relate)
boolean = try_attrib (class_x, attribute_y, 5)
Will return true if you can assing 5 to attribute_y on class_x, false if you
can't!
I also didn't mention:
Custom types and V-types can be used like this:
my_class[my_attribute]
Methods like this:
my_class = call_func(my_class[my_attribute],{my_class, other_arguments})
Procedures:
call_proc (my_class[my_attribute],{my_class, other_arguments})
Functions: (Do not store their value into the class!! They can not modify
the class, use a Method for that instead!)
returnvalue = call_func (my_class[my_attribute], {my_class,
other_arguments})
You can find routines to acces functions, methods, procedures and values,
but is that really needed ??
I think people have a better understanding what went right/wrong when they
do this themselves.
--[extra documentation]
>By my count, that makes four contributions for Euphoria OOP extentions:
>
>1. Francis Bussiere's (from *way* back when)
>2. Irv's (in Windoz)
>3. My own (in WinMan)
>4. Yours [Ralf's].
Well, the old one by Francis Bussiere doesn't even use routine pointers.
And yours and Irv's are backed in your code.
The reason I wrote this is because I couldn't strap neither your or Irv's
code.
Not to have another flavor (althrough like everybody, I'm convienced my
approuch is the best, I guess its just a personal taste.)
>Everyone but me seems to use type checking on their OOP attributes. I guess
I'll cave and add some to my package, too.
Well, developping NGL I found it was very hard to trace errors back.
Now I use crash_message () a lot, so you really see what went wrong.
A custom attribute type can also use this, by setting the global sequence
error_message. It will be used in the total error message displayed on the
screen.
And I added a oop_trace (1), which instead of generation a type check error
turns tracing on, however it does display the error message on the screen.
And trace is turned off in oop.e so the trace screens displays your code
only.
>> It is what I am using for NGL.
>
>I can hardly wait. Your prior blurb looked very interesting. Will it
support VGA as well?
Well, like I said it is a bridge. All video modes in Euphoria will be
enabled.
But all the code and thinking is about the fact that you can "plug-in" a
device.
You can fastly create a video device for NGL.
In fact only having an routine to open the video mode and one to put a pixel
on the screen is enough.
The rest is then emulated using the pixel routine.
But if you think you can do it faster, you can overwrite any of the extended
drawing commands.
(Command is a definition of a routine iD, ASM-Code or DLL-Link that NGL uses
to make the fastest command list possible)
>[Dot Notation]
>is cool even without it being OOP. I liked it so much, I went ahead and
wrote a pre-processor. It's called Dot, and is on the Euphoria Web page. The
latest version (sent in this morning) can be used in EE in place of PP - not
that I expect anyone to really latch onto it.
Well, if you combined PP & Dot, added color-syntaxing for them and put it on
as default, many people might use. I know I will. Especially the slice looks
a lot more clear.
>As I mentioned, it's not OOP - but you can certainly combine it with an OOP
package.
Yes, append () and slice () can be considered attributes of the class
sequence and thus available to any class
based upon a sequence. (Which class isn't based on seqs??)
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
7. Re: Classes: A small proposal
- Posted by Falkon <Falkn13 at IBM.NET>
Jun 02, 1998
-
Last edited Jun 03, 1998
From: David Cuny
>You could declare attributes with:
> point attribute x, y
>which would be internally:
> global constant point:x = 1, point:y = 2
[...]
> point function func( integer x )
Two things I notice about this:
First, IMHO, constants used by a class should be local to that class, not
using up global namespace. Otherwise it would negate the modularity of OOP,
being able to plug classes together easily, without extensive modification,
to make a program.
Secondly, I find the declaration syntax somewhat confusing. Mixing up
what your declaring with what you're declaring it to be. My vision of it
goes kind of like this:
-----class declaration-------
class car
parents = vehicle --if multiple, then list in order of inheritance
attributes =
coordinate position --assuming coordinate is a declared data type
integer wheels
boolean running --assuming boolean is a declared data type
methods =
PROC startup( car )
ID = routine_ID( "carstart" )
FUNC driveto( car, coordinate )
returns boolean
ID = routine_ID( "cardriveto" )
end class
---------and for object declaration-----
object Mustang
class = car
name = "Ford Mustang" --inherited attribute
position = { 100, 45 }
running = NO
end object
-----and for method declaration and attribute setting,----
-----normal EU but with dot notation allowed ----
procedure carstart( car CarToStart )
CarToStart.running = YES
end procedure
function cardriveto( car CarToDrive, coordinate Destination )
if CarToDrive.running then
CarToDrive.location = Destination
return( TRUE )
else
return( FALSE )
end if
end function
---------------------------
My idea would require a separate include file for each class though.
(containing the class structure, descriptors, and methods) so it would need
a project/class/include manager, and a preprocessor, and some other stuff
too... But it would allow for multiple inheritance, message-passing, and
dynamic overriding of methods. Plus you could programmatically examine a
class to see what datatype a method's arguments and return value are, and so
on.
IMHO it looks more natural and more like standard Euphoria, but that's
just my opinion. And it shouldn't be too difficult to convert existing
libraries to classes...
To override a method, all you'd have to do is change the value of the
method descriptor's ID variable. I've wondered whether to disable that. It
seems most people are opposed to this sort of 'dynamicness', and it could
end up confusing and messy. But it is possible, and could be powerful. Now
I see that apparently most people don't like multiple inheritance either,
(though it seems practically necessary from what I understand of OOP). What
are the arguments against it? Seems as though it would make combining
classes much easier and prevent a lot of unnecessary code duplication.
Anyhow, I put everything else aside to play with this. I'm in the
middle-design stages with ideas scattered through my notebook, half a dozen
text files, a few diagrams, and about a third of one file of the core
routines done. I think the core routines will be about 5 files containing
message-handling; class, object, property, and method declaration and
manipulation; and program structure code.
How to enable constraints and multiplicity on the allowed values of a
property is what's bugging me the most... That and timing. I can easily
schedule a message to be sent after say...5 iterations through the main
loop, but I can't see any easy way to schedule one to be sent in say, 15
seconds. Not knowing how long it will take to go through the loop.
I'll try to put it all together into something less jumbled so the rest
of you can look at it, and maybe make sense of it. And compare it to the
others. I have no experience at OO programming, so I could use any
'real-world' thoughts that don't come from a theory book.
From: Ralf Nieuwenhuijsen
>The reason I wrote this is because I couldn't strap neither your or Irv's
>code.
>Not to have another flavor (althrough like everybody, I'm convienced my
>approuch is the best, I guess its just a personal taste.)
Diversity is good. :) The reason I started on this is that I have had
trouble understanding and figuring out what would need to be modified in the
'custom' systems to make them generic, all-purpose OOP systems. That and
the quest for clear namespace and easier attribute manipulation. I'm not
convinced that my approach is the best, in fact it's seeming as though any
of the others would be less complex. But my idea seems powerful. Of course
it hasn't been implemented yet tho.
8. Re: Classes: A small proposal
> My idea would require a separate include file for each class though.
>(containing the class structure, descriptors, and methods) so it would need
>a project/class/include manager, and a preprocessor, and some other stuff
>too... But it would allow for multiple inheritance, message-passing, and
>dynamic overriding of methods. Plus you could programmatically examine a
>class to see what datatype a method's arguments and return value are, and
so
>on.
Well, with an pre-proccesor, this would indeed by "real" oop.
I avoided the namespace problem, you mentioned, by a set of rules:
classnameMAttributename --where the 'M' stands for Method. (a
reminder)
Without a pre-proccesor, you would still need to have all your attributes in
a sequence, instead of using locals, which would be the most perfect.
Not to mention that accesing a class containing a class containing a class,
requires *three* routine calls, and *three* subscripts using all optimize
tricks in the book.
People tend to require speed. Esspecially for those large programms all this
OOP crap we've been producing
I use Euphoria, because of all *practicle* languages out there, this
language *also* has a good theoretic base. The best compared to all
languages I've seen. But then again, like Euphoria there all zillions of
underground languages with interesting theoretics. But you are almost always
not practicle. Slow, incompatible, memory troubles. Programming languages
are only interesting if there is *usable* *practicle* implementation,no
matter how brilliant their grammatics are.
We could even have a true, pure oop system using messages, keeping all
attributes and class names in sequenses. But even my PII gets a bit scared
of that.
> IMHO it looks more natural and more like standard Euphoria, but that's
>just my opinion. And it shouldn't be too difficult to convert existing
>libraries to classes...
You can write a preproccesor that converts any library to a class.
All locals are private attributes.
All globals are public attributes. (but all put in a local sequence
together, with their name)
Then the preproccesor adds a manager, the only globally defined thing.
Namespace problem solved. Pure oop. Speed down to .001%
The reason Euphoria can compete with JIT, is because JIT wants to be
pure OO.
This could only be implemented by RDS themselves, because they check the
namespace thing during the pre-procces. That's why a passes routine pointer
of a local routine works from another file.
> To override a method, all you'd have to do is change the value of the
>method descriptor's ID variable. I've wondered whether to disable that.
It
>seems most people are opposed to this sort of 'dynamicness', and it could
>end up confusing and messy. But it is possible, and could be powerful.
Now
It is required, this is the only way to apply inheretence.
>I see that apparently most people don't like multiple inheritance either,
>(though it seems practically necessary from what I understand of OOP).
What
No, it's the complete oposite of OO.
Combining diffent classes, is appending different .E files together. A
namespace hell.
And is it never needed.
An example David Cuny mentioned. All objects in his WinMan can be in
different states and thereby look a bit different. (they can all be pushed,
and thus moved to the left and down, they can all de disabled: gray, etc.)
You could inherit it. Or you could have an instance of it, as an
attribute in your class. Much cleaner.
OOP was to solve namespace. Multiple Inheretence is the hack to get rid
of OOP's strict namespace rules. It is the oposite of the ideology behind
OOP.
>are the arguments against it? Seems as though it would make combining
>classes much easier and prevent a lot of unnecessary code duplication.
You don't need it. Why inherit. Use it as an attribute. Keep your stuff
ordered. Not mix everything together and see it doesn't get any namespace
problems!!
> Anyhow, I put everything else aside to play with this. I'm in the
>middle-design stages with ideas scattered through my notebook, half a dozen
>text files, a few diagrams, and about a third of one file of the core
>routines done. I think the core routines will be about 5 files containing
>message-handling; class, object, property, and method declaration and
>manipulation; and program structure code.
I will look forward to see it. Try to keep it fast through. You have a few
nice comments.
Is it gonna be a library or a pre-proccesor ?
> How to enable constraints and multiplicity on the allowed values of a
>property is what's bugging me the most... That and timing. I can easily
I've used a type-check header. For every attribute is also a routine iD
available to check its value.
>schedule a message to be sent after say...5 iterations through the main
>loop, but I can't see any easy way to schedule one to be sent in say, 15
>seconds. Not knowing how long it will take to go through the loop.
Timing ? You want to go event based ? Please not. I've already been in
the VB hell.
> I'll try to put it all together into something less jumbled so the
rest
>of you can look at it, and maybe make sense of it. And compare it to the
>others. I have no experience at OO programming, so I could use any
>'real-world' thoughts that don't come from a theory book.
'real-world' throughts. I always assumed it was the other way around.
People are used to certain things in the real-world, so they overlook
the theoretic possibilities.
A theory is putting stuff in a relation to each other. It gives the best
overview. Then again, books don't teach theory, they teach how to use an
already made up theory. So I guess we mean the same.
>From: Ralf Nieuwenhuijsen
>>The reason I wrote this is because I couldn't strap neither your or Irv's
>>code.
>>Not to have another flavor (althrough like everybody, I'm convienced my
>>approuch is the best, I guess its just a personal taste.)
>
> Diversity is good. :) The reason I started on this is that I have
had
>trouble understanding and figuring out what would need to be modified in
the
>'custom' systems to make them generic, all-purpose OOP systems. That and
>the quest for clear namespace and easier attribute manipulation. I'm not
Well, a leave the namespace (local, global) up to Euphoria by assign
attributes indexes to a constant.
This way, it looks more natural and fits better in with the code.
>convinced that my approach is the best, in fact it's seeming as though any
>of the others would be less complex. But my idea seems powerful. Of
course
>it hasn't been implemented yet tho.
The more different methods and libraries that come available. The better
over-view we get.
Good luck. But the example code above introduces many new keywords and
new grammer-rules. Why not try to make it look like Euphoria code as much as
you can do, because the above code, no offence, looks like shit. Captials,
words as "proc", why not use the same word "procedure" as Euphoria does?
It might type faster, but now we need three hours to get the bugs out of
200 lines of code.
But that's just syntactic sugar as David has named it often. I would be
interested to see your theory at work.
Ralf Nieuwenhuijsen
nieuwen at xs4all.nl
9. Re: Classes: A small proposal
BTW.. I've updated my documentation of OOP.
I've added a section describing the common problems you can have with
Euphoria & OO.
Like two classses that need to have an equal relation ship. (In Euphoria
order is critical. You can't use a class not already defined, but if that
class needs you to be defined also... etc.)
PS Not only the problems, but also the *working* solutions are presented.
Like that a few other problems are mentioned.
Irv has been so kind to have the documentation into a HTML doc.
BTW I would love to get feedback from people nor familiar with OO about my
documentation. I've tried to make it more than just an explenation of this
OO implementation for Euphoria.
Irv's Euphoria Programming Archive: (IEPA)
http://www.mindspring.com/~mountains/
Ralf
10. Re: Classes: A small proposal
At 11:19 PM 6/2/98 -0400, Falkon wrote:
>..... declaring with what you're declaring it to be. My vision of it
>goes kind of like this:
-- Falkon's stuff --
As someone who has only been skimming the OOP debate
this stood out to me as being instantly understandable
and clear to read. Maybe I live in the real world too.
Ralf:
I realize English is your second launguage so here
is a new word for you: Profane
Your posts are becoming increasingly profane.
It is simply unnesessary and detracts from the
credability of your views.
I do, however, prefer 'procedure' to 'PROC'
Graeme.
----------------------------------------------------
11. Re: Classes: A small proposal
>Ralf:
>
>I realize English is your second launguage so here
>is a new word for you: Profane
>
>Your posts are becoming increasingly profane.
>It is simply unnesessary and detracts from the
>credability of your views.
Yes, I did need to look that word up.
Did I really sound unfriendly ? I didn't mean to.
I always thought you people got offended by me, because I don't much of the
'context' that words are placed in. Some words don't have a direct negative
meaning, but are interpretered like that, because they are often used for
that purpose. I will state once more that I really don't mean stuff
unfriendly.
But I am now starting to think, this is more a cultural difference. I am not
used to people getting insulted by words this easily. Most people I talk to
don't take things personally, nor get all kinds of emotions during a
discussion. The goal in a discussion is not to get your right, but to get
*it* right. And the ideas are what is being discussed. IMHO the ideas are
the only one that could get insulted by me. I don't understand why this kind
of message can upset any one. Ok, normally people hear your voice, but why
expect the most negative?
The truth is, most of the times, I reread my message and make it a little
bit more political, a bit more friendly. I've learned that speaking to
Americans requires that behaviour. And yes, lately that has skipped a couple
of times. However, about the message you are refering to was added some
friendly stuff.
Still, I think, after a while, some stuff doesn't have to be said. If I mean
something as a flame, trust me, there will be no doubt that that is not due
to my lack of command of English. I mean, I'm just a 16-years old boy, how
in the world can I get any of you upset anyway ?
I think this is enough about that. You shouldn't have placed such a personal
message on the list-serv anyway, but because you did, I'll take this chance
to apologize to any one that did get insulted. Just get it right this time,
I dont' mean it unfriendly, nor do I look down on any of you. Do I really
need to put zillions of smileys every where to prove that ?
Ralf
12. Re: Classes: A small proposal
At 08:00 AM 6/4/98 +0200, Ralf wrote:
,,, I really don't mean stuff unfriendly.
>
>But I am now starting to think, this is more a
>cultural difference. I am not used to people getting
>insulted by words this easily. Most people I talk to
>don't take things personally, nor get all kinds of
>emotions during a discussion.
Ralf:
You are right. It is a cultural difference.
The US (at least large parts of it) is a country
where, for example, people want to kill anybody that happens
to be in front of them on the freeway. Sometimes they
do, if they think they can get away with it.
Always assume you're dealing with 5-year-olds with a bad
temper (and access to atomic weapons). You won't be far
from the truth.
Irv
13. Re: Classes: A small proposal
From: Ralf Nieuwenhuijsen
>People tend to require speed. Esspecially for those large programms all
this
>OOP crap we've been producing
Eh, I've wondered about that. Seems like all the handle lookups and
multiply subscripted sequences might slow things down considerably. But I
suppose that's the price you have to pay to use OOP, to some degree.
re: multiple inheritance
> You could inherit it. Or you could have an instance of it, as an
>attribute in your class. Much cleaner.
Ahh, that makes sense! Sounds clear. I hadn't thought of that. It
would mean nesting deeper and double/triple more subscripting to access a
value I suppose, but it might turn out cleaner in the long run.
re: attribute value constraints
> I've used a type-check header. For every attribute is also a routine iD
>available to check its value.
I'm looking at your code and liking that. I'd hoped to do it 'more
simply', using a semistandard notation for common things like multiplicity
restrictions, but the simpler I try to make it the more complex it gets. :(
>But the example code above introduces many new keywords and
>new grammer-rules.
Well, in the case of the declarations, the grammar is pretty much the
same as any Euphoria declaration, except that I left out the brackets and
snipped the redundant parts of the subscripting because it follows a set,
known pattern for every class and object.
The actual underlying data for that example class would look something like
this, but not exactly:
{"car",
{"vehicle"},
{{"position", COORDINATE },
{"wheels", INTEGER },
{"running", BOOLEAN}},
{{"startup", {"car"}, NONE, routine_ID("carstart")},
{"driveto", {"car", COORDINATE }, BOOLEAN, routine_ID("cardriveto")}},
{}
}
Because in my version, all classes have the same structure of 5 parts;
{ name, --string
{parents}, --sequence of strings (1 string if no multiple
inheritance),
{property descriptors},
{method descriptors},
{currently existing instance handles}
}
Objects are simply a sequence of 3 parts;
{ name, --string
class, --classhandle (or string name?)
{values} --sequence of one value for each property, of the correct
} -- datatype and fitting restrictions
This is different from yours and others, I believe, in that I treat
objects separately from classes. Because all objects of the same class must
have the same methods and property constraints, there's no need to duplicate
them.
The only new keywords were class and object. Object wasn't new, but had a
different meaning. Perhaps that wasn't clear. The rest of the 'new' words
were just a way of using preprocessing to eliminate the ugliness and
confusion of defining hundreds of (possibly conflicting) constants for all
your datatypes, classes, and subscripting. Or declaring everything via
routines.
That's another thing that bugs me with most of the current models, is
that you must declare complex structures like classes by using lots of
routine calls. I'd prefer a cleaner declarative syntax.
Of course, to echo a phrase, that's just syntactic sugar.
>Captials, words as "proc", why not use the same word "procedure" as
Euphoria >does?
Ah, you got me there. PROC and FUNC were constants, a throwback to when
I started this, before I was thinking in terms of preprocessing. So PROC
and FUNC can be changed or done away with. I could just say that any method
which has a return value of NONE is a procedure, any that has a return value
is a function.
>We could even have a true, pure oop system using messages, keeping all
>attributes and class names in sequenses. But even my PII gets a bit scared
>of that.
> Timing ? You want to go event based ? Please not. I've already been in
>the VB hell.
Well I don't know about the true or pureness of it, but that is pretty
much my basis. Reusable classes of data objects with declared instances
communicating through messages and all that stuff. Speed and RAM usage do
become problems though. If I did away with the message-handling and
statechecks, classes and objects could still be used for data storage in
functional programs, but that seems to somewhat sidestep the point.
What I'm going to do is look through Irv's and David's and your code
some more, compare it to my notes, and see if I might do better to just
write a preprocessor based on that existing code. And then add
message-handling and statecheck code as an optional part of the system for
those programs/people for which it would be appropriate.
Falkon
14. Re: Classes: A small proposal
Last time I tried this, Greame got upset, so I consider this an appeal and
am awaiting for the result of the jury ;- ) (that was a joke, no not
nessecarily humor
>>People tend to require speed. Esspecially for those large programms all
>this
>>OOP crap we've been producing
>
> Eh, I've wondered about that. Seems like all the handle lookups and
>multiply subscripted sequences might slow things down considerably. But I
>suppose that's the price you have to pay to use OOP, to some degree.
Then again, you are gonna make a preproccesor, which will off course always
produces the best speed.
>re: multiple inheritance
>> You could inherit it. Or you could have an instance of it, as an
>>attribute in your class. Much cleaner.
>
> Ahh, that makes sense! Sounds clear. I hadn't thought of that. It
>would mean nesting deeper and double/triple more subscripting to access a
>value I suppose, but it might turn out cleaner in the long run.
It is also impossible for me and David, because we are using constants to
store the element number of an attribute.
I must admit, it does cost *some* speed, but keeping names and attributes in
sequences as you do, is the only way you can have true OOP systems, it also
slows it down even more.
If you are gonna make a preproccesor you should consider, that you really
don't need to store any atribute and class names during run-time, unless off
course, you would want to be able to choose the name of a class or the name
of an attribute during run-time. This would indeed be very cool. Althrough I
do not know a direct use for it, it does fit better in with Euphoria dynamic
attitude than any of our approuches.
>re: attribute value constraints
>> I've used a type-check header. For every attribute is also a routine
iD
>>available to check its value.
>
> I'm looking at your code and liking that. I'd hoped to do it 'more
>simply', using a semistandard notation for common things like multiplicity
>restrictions, but the simpler I try to make it the more complex it gets.
:(
One of the best things preproccesor off, that libraries don't is a new-clear
syntax.
>>But the example code above introduces many new keywords and
>>new grammer-rules.
>
> Well, in the case of the declarations, the grammar is pretty much the
>same as any Euphoria declaration, except that I left out the brackets and
>snipped the redundant parts of the subscripting because it follows a set,
>known pattern for every class and object.
> This is different from yours and others, I believe, in that I treat
>objects separately from classes. Because all objects of the same class
must
>have the same methods and property constraints, there's no need to
duplicate
>them.
Another difference is that you handle methods and attributes seperately.
In my code an method is just an attribute, it's a value.
Only you can use call_proc () or call_fun () to use it as an method.
This doesn't look very nice, and could be solved by a preproccesor.
The reason I choose for this, is that you can change the routine for a
method. Now I think about it, that is not OOP, and many ordening problems
could be solved by keeping methods as global routines. (linstead of having a
global constant pointing to an element) I will change this for my OOP
library. However transformations are then not possible anymore.
> The only new keywords were class and object. Object wasn't new, but had
a
>different meaning. Perhaps that wasn't clear. The rest of the 'new' words
>were just a way of using preprocessing to eliminate the ugliness and
>confusion of defining hundreds of (possibly conflicting) constants for all
>your datatypes, classes, and subscripting. Or declaring everything via
>routines.
About the term 'object'. Be carefull you don't break any existing code.
Yes, all attributes are defined as global constants.
You need a stict name spacing rules will this work for big programs.
Then again, if you are making a preproccesor, this wouldn't matter at all!
Cause you could check the misuse of any of these globals yourself. And
replace their name with a name you are sure is never used. (Random names
like: "dfklf494mf") The preproccesor in ex.exe works the same way. It checks
the scope rules and your code. But if it would by mistake allow a program to
acces a local from another file, it would have worked. It is a restriction
layed upon us by the preproccesor, which replaces all variables with 32-bit
memory addreses. (using the fast 4-byte machine integer).
> That's another thing that bugs me with most of the current models, is
>that you must declare complex structures like classes by using lots of
>routine calls. I'd prefer a cleaner declarative syntax.
Yep, using routines to declare an attribute makes code look nice. Using an
preproccesor can make code look even nicer.
>Of course, to echo a phrase, that's just syntactic sugar.
>>We could even have a true, pure oop system using messages, keeping all
>>attributes and class names in sequenses. But even my PII gets a bit scared
>>of that.
>> Timing ? You want to go event based ? Please not. I've already been in
>>the VB hell.
Oh, wait, Greame, Did you mean this ?
Well, ok, I can understand you got upset, not share your feelings though.
> Well I don't know about the true or pureness of it, but that is pretty
>much my basis. Reusable classes of data objects with declared instances
>communicating through messages and all that stuff. Speed and RAM usage do
>become problems though. If I did away with the message-handling and
>statechecks, classes and objects could still be used for data storage in
>functional programs, but that seems to somewhat sidestep the point.
>
> What I'm going to do is look through Irv's and David's and your code
>some more, compare it to my notes, and see if I might do better to just
>write a preprocessor based on that existing code. And then add
>message-handling and statecheck code as an optional part of the system for
>those programs/people for which it would be appropriate.
Well, I do get scared of message handling in an procedural language. But for
windows-programming it's critical anyway. My code can have events. The
routine-iD of an method is saved within the sequence and can thus be changed
in run-time. Think about it. It would be cleaner to extend the syntax for
this.
Good luck with your preproccesor.
Ralf
